대용량 복구가 중간에 실패함

제품 지원
1

다시 인사드립니다! 이전에 공유했던 이전 작업을 잠시 보류했다가 다시 진행했습니다. 원래 설치되어 있던 (오래된) 호스트에서 몇 가지 문제가 발생하면서 상황이 조금 더 시급해졌습니다.

배경: 새 인스턴스로 이전하는 과정에서 외부 PG와 Redis 인스턴스로의 이전을 함께 진행하기로 결정했습니다. 신규 설치 설정은 문제없이 완료되었고, 이전 작업 자체는 커맨드 라인을 통해 백업 + 복원 방식으로 수행할 계획입니다. 현재는 워크플로우를 테스트하고, 원래 인스턴스를 읽기 전용으로 설정하고 진행하기 전에 새로 복원된 인스턴스가 예상대로 작동하는지 확인하는 중입니다. 특히 이 인스턴스가 상당히 오래되고 규모가 크기 때문에 더욱 신중을 기하고 있습니다.

기존 인스턴스: 표준 방식으로 PG, Postgres, Redis가 함께 설치된 단일 인스턴스의 간단한 셀프 호스팅 설정입니다.
새 인스턴스: 동일한 app.yml을 사용하지만, 외부 관리형 PG + Redis(DigitalOcean)를 사용합니다.

복원 명령은 상당한 시간 동안 정상적으로 진행되는 것처럼 보입니다. 그러나 상당한 시간이 지난 후, 실행마다 일관되게 다음과 같은 오류가 발생합니다(문맥을 위해 일부 성공 로그 포함):

COPY 99820
COPY 3216770
COPY 3251307
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
invalid socket
connection to server was lost
EXCEPTION: psql failed: connection to server was lost
/var/www/discourse/lib/backup_restore/database_restorer.rb:95:in `restore_dump'

실행마다 서로 다른 특정 COPY 지점에서 발생했으므로, 제가 파악한 바로는 이는 이전 작업 자체에 특정한 문제가 아닌 것 같습니다. DB 연결이 모두 정상적으로 작동하는 것이 명확하므로, 이는 DigitalOcean의 동작과 관련된 문제라고 추정하는 것이 안전할 것입니다. 하지만 여기에서 비슷한 현상을 경험하신 분이 계셔서 올바른 방향으로 이끌어 주시기를 바랍니다.

2

관리형 PG 인스턴스이므로 해당 서비스의 로그를 확인해야 합니다.

(항상 로그를 확인하세요!)

예를 들어, 최대 연결 수명(maximum connection lifetime)이 설정되어 있고 복구가 완료되는 데 더 오래 걸리는 경우와 같이, 왜 이런 일이 발생했는지에 대한 이유를 알려줄 수 있습니다.

3

음… 아, 저… 로그를 확인해 봤는데, Discourse 로그에서 봤던 정보와 대부분 같았어요. 그런데 과거 로그를 더 파고들다 보니 해당 시점前后的 그래프를 실제로 확인하게 되더라고요… 테스트 DB 용량을 너무 작게 잡았었거든요 :facepalm: 그래서 DB가 가득 차고, DO(DigitalOcean)가 그냥 연결을 끊어버렸어요. 아뿔사.

모든 것을 다시 리사이즈했고, 좀 멍청하게 굴었지만 다시 경쟁에 합류했습니다.