Крупное восстановление завершается неудачей на полпути

Поддержка
1

Снова привет! Я отложил последнюю миграцию, о которой писал, но вернулся к ней. Ситуация стала немного более срочной из-за проблем на (устаревшем) хосте, где изначально размещалась установка.

Контекст: Во время миграции на новый экземпляр я решил сразу же перейти на внешние экземпляры PostgreSQL и Redis. Настройка чистой установки прошла успешно, и я планирую выполнить миграцию с помощью команды резервного копирования и восстановления из командной строки. В данный момент я просто тестирую рабочий процесс и проверяю, что восстановленный экземпляр работает как ожидалось, прежде чем перевести исходный экземпляр в режим только для чтения и продолжить, особенно учитывая, что это довольно старый и большой экземпляр, который я мигрирую.

Старый экземпляр: простая настройка самостоятельного хостинга, один экземпляр со стандартными встроенными PostgreSQL и Redis.
Новый экземпляр: тот же app.yml, но с внешними управляемыми экземплярами PostgreSQL и 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'

Это происходило в разных точках копирования при различных запусках, поэтому, насколько я могу судить, это не связано с самой миграцией. Учитывая, что соединения с БД явно работают, я считаю, что можно с уверенностью предположить, что это связано с особенностями работы DigitalOcean, но я надеюсь, что кто-то из присутствующих здесь уже сталкивался с подобным и сможет указать мне правильное направление.

2

Поскольку это управляемый экземпляр PostgreSQL, вам следует проверить логи этого сервиса.

(всегда смотрите логи!)

Возможно, там будет указано, почему это произошло, например, может быть настроено максимальное время жизни соединения, а восстановление занимает больше времени, чем ожидалось.

3

Ну… я, э-э… проверил логи, и там в основном была та же информация, что я видел в логах Discourse, но углубление в них заставило меня действительно посмотреть исторические графики за то время… Я недооценил тестовую БД :facepalm:, поэтому она заполнилась, и DO просто разорвал соединение. Эх.

Изменил размеры всего, чувствуем себя глупо, но снова в гонку.