ERROR: WAL segment ... could not be streamed in 300 seconds (FULL Backup on Master)

[makeconfig2017]

Здравствуйте,

Сегодня при создании полной копии на мастер-сервере в режиме STREAM бэкап завершился с ошибкой:
ERROR: WAL segment 0000000100026C4E0000001C could not be streamed in 300 seconds

Бэкап запускался на мастер-сервере в режиме STREAM командой:
pg_probackup backup -j 12 --compress -U bckpusr -B /PROBACKUP --instance INST1 -b FULL --stream --temp-slot

На котором настроено непрерывное архивирование WAL на слейв-сервер:
wal_level = replica
archive_mode = on
archive_command = 'rsync -aq %p PGUSR@1.1.1.1:/ARCHIVE/%f'

Вот тут описана эта ошибка, но при бэкапе на слейв-сервере (реплике) и коментарий:
As you are using archiving, you don't need to use --stream option.

Если возможно, ответьте пожалуйста, получится ли полное восстановление (без потери данных), если бэкап сделан на мастер-сервере в режиме ARCHIVE (без режима --stream), в случае отказа всего кластера (и мастера и слейва) ?

[gsmolk]

Добрый день.

ERROR: WAL segment 0000000100026C4E0000001C could not be streamed in 300 seconds

Можете прислать полный лог выполнения бэкапа и его метаданные (pg_probackup show -i айдюк)?

Я правильно понимаю, что:

1. бэкапы совершаются и хранятся на мастере локально
2. Архивирование идет с мастера на реплику

?

[makeconfig2017]

Да, бэкапы делаются на мастере и хранятся локально. Архивирование идет с мастера на реплику.
К сожалению полный лог прислать не могу, расширенное логирование не было включено, вот все что есть:
INFO: Backup start, pg_probackup version: 2.4.4, instance: INST1, backup ID: QJ6W9N, backup mode: FULL, wal mode:
STREAM, remote: false, compress-algorithm: zlib, compress-level: 1
WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'.
INFO: PGDATA size: 2870GB
INFO: Start transferring data files
INFO: Data files are transferred, time elapsed: 1h:22m
INFO: wait for pg_stop_backup()
INFO: pg_stop backup() successfully executed
INFO: Wait for LSN 26C4E/1C48AD00 in streamed WAL segment /PROBACKUP/backups/INST1/QJ6W9N/database/pg_wal/0000000100026C4E0000001C
ERROR: WAL segment 0000000100026C4E0000001C could not be streamed in 300 seconds
WARNING: Backup QJ6W9N is running, setting its status to ERROR

pg_probackup show:
BACKUP INSTANCE 'INST1'
================================================================================================
Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status
================================================================================================
INST1 10 QJ6W9N ---- FULL STREAM 1/0 1h:27m 853GB 0 3.36 26C46/1E009360 0/0 ERROR

[gsmolk]

По первоначальной проблеме, скорее всего Вам поможет этот фикс в грядущей версии 2.4.5 - 59251c3

Если возможно, ответьте пожалуйста, получится ли полное восстановление (без потери данных), если бэкап сделан на мастер-сервере в режиме ARCHIVE (без режима --stream), в случае отказа всего кластера (и мастера и слейва) ?

Для того, чтобы полагаться на архив при снятии бэкапов, архив должен располагаться с том же хосте, на котором запускается бэкап. Поэтому в вашем случае снятие бэкапа просто зафейлится.

Я бы предложил Вам пересмотреть вашу схему резервного копирования, т.к. у нее есть объективные недостатки:

1. Смерть машины с мастером заберет с собой и бэкапы
2. Архив и бэкапы не знают ничего друг о друге, из-за чего процесс резервного копирования в целом выглядит неэффективно

Есть ли возможность перенести бэкапы на другую машину?

[makeconfig2017]

Архив должен располагаться на том же хосте, на котором запускается бэкап

Не уверен, но возможно получится, в настоящий момент упираемся в дисковое пространство

Архив и бэкапы не знают ничего друг о друге, из-за чего процесс резервного копирования в целом выглядит неэффективно

Не подскажете в какую сторону нужно смотреть, возможно нужно как-то совместить архивирование на реплику текущими средствами (через rsync) с архивированием средствами pg_probackup как описано здесь

[gsmolk]

Не уверен, но возможно получится, в настоящий момент упираемся в дисковое пространство

А не думали перенести бэкапы на реплику?

Не подскажете в какую сторону нужно смотреть, возможно нужно как-то совместить архивирование на реплику текущими средствами (через rsync) с архивированием средствами pg_probackup как описано здесь

Архивируете на реплику из-за нехватки места на мастере?

[makeconfig2017]

А не думали перенести бэкапы на реплику?

Думали, но удаленно (локально не можем из-за нехватки дискового пространства) с реплики снимать в режиме STREAM не вышло, шли WARNING'и:
WARNING: Could not read WAL record at 3034/2E4F8350: invalid record length at 3034/2E4F8350: wanted 24, got 0
INFO: Wait for LSN 3034/2E4F8350 in streamed WAL segment
/PROBACKUP/backups/INST1/QIWTKU/database/pg_wal/00000004000030340000002E
WARNING: Could not read WAL record at 3034/2E4F8350: invalid record length at 3034/2E4F8350: wanted 24, got 0

Архивируете на реплику из-за нехватки места на мастере?

Архивируем на реплику для создания стендбая, в случае отказа активируется реплика (правда вручную)

Скорее всего Вам поможет этот фикс в грядущей версии 2.4.5 - 59251c3

Не собралось с postgresql-9.6.19:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -fPIC -m64 -DFRONTEND -I. -I./ -I/PGBIN/pgsql-9.6/include/server -I/PGBIN/pgsql-9.6/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -I/PGBIN/pgsql-9.6/include -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -Isrc -I/PGSRC/postgresql-9.6.19//src -c -o src/backup.o src/backup.c
src/backup.c: In function ‘StreamLog’:
src/backup.c:2518:6: error: ‘StreamCtl’ has no member named ‘do_sync’
ctl.do_sync = false; /* We sync all files at the end of backup */
^
make: *** [src/backup.o] Error 1

[gsmolk]

Думали, но удаленно (локально не можем из-за нехватки дискового пространства) с реплики снимать в режиме STREAM не вышло, шли WARNING'и:
WARNING: Could not read WAL record at 3034/2E4F8350: invalid record length at 3034/2E4F8350: wanted 24, got 0
INFO: Wait for LSN 3034/2E4F8350 in streamed WAL segment
/PROBACKUP/backups/INST1/QIWTKU/database/pg_wal/00000004000030340000002E
WARNING: Could not read WAL record at 3034/2E4F8350: invalid record length at 3034/2E4F8350: wanted 24, got 0

Ну так это нормально для бэкапа с холодной реплики, нужно настроить archive_timeout на мастере. Давайте вернемся к этому варианту.

Архивируем на реплику для создания стендбая, в случае отказа активируется реплика (правда вручную)

А что такое стендбай в вашем случае и чем он отличается от реплики?

Не собралось с postgresql-9.6.19:

Попробуйте a5feea2

[makeconfig2017]

Нужно настроить archive_timeout на мастере

В документации пишут устанавливать этот таймаут не больше минуты. Не получится так, что начнет забиваться архив или WAL (на мастере или на реплике), при большой активности например ? (возможно тут ошибаюсь)

Давайте вернемся к этому варианту.

Для всех случаев не подойдет, но в идеале конечно хотелось бы видеть именно такой вариант (это было бы просто прекрасно)

А что такое стендбай в вашем случае и чем он отличается от реплики?

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

Попробуйте a5feea2

Спасибо, собралось, правда postgresql-9.5.23 с этой версией (59251c3) собрался без ошибок

[gsmolk]

В документации пишут устанавливать этот таймаут не больше минуты. Не получится так, что начнет забиваться архив или WAL (на мастере или на реплике), при большой активности например ? (возможно тут ошибаюсь)

При большой активности как раз отрицательных последствий от этого параметра нет. Я бы рекомендовал поставить 4min, что даст pg_probackup с его archive_timeout в 5min необходимый запас времени для получения сегмента на реплике.

Для всех случаев не подойдет, но в идеале конечно хотелось бы видеть именно такой вариант (это было бы просто прекрасно)

Что останавливает?

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

Почему нельзя просто запромоутить уже имеющуюся реплику в случае падения мастера?

[gsmolk]

Закрываем задачку?

[makeconfig2017]

Добрый день, при попытке локального бэкапа pg_probackup'ом скопилированным с патчем, выело все возможное место на диске и так и не забэкапилось.

Я бы рекомендовал поставить 4min, что даст pg_probackup с его archive_timeout в 5min необходимый запас времени для получения сегмента на реплике.

Спасибо за совет, но пока ещё не попробовали, переживаем что реплика может очень отстать.

Почему нельзя просто запромоутить уже имеющуюся реплику в случае падения мастера?

Да, так и делаем, промоутим реплику в случае падения мастера.

[gsmolk]

Добрый день, при попытке локального бэкапа pg_probackup'ом скопилированным с патчем, выело все возможное место на диске и так и не забэкапилось.

Ну это одна из причина, почему бэкапить базу локально - плохая идея.

Да, так и делаем, промоутим реплику в случае падения мастера.

Тогда непонятно, в чем у Вас заключается отличие стендбая от реплики.

[makeconfig2017]

Тогда непонятно, в чем у Вас заключается отличие стендбая от реплики.

Да, Вы правы, это реплика, по незнанию думал, что это одно и то же.

Ну это одна из причина, почему бэкапить базу локально - плохая идея.

Согласен полностью.

[gsmolk]

Фикс помог? Стриминг начал успевать?