Closed ktulkhu closed 1 year ago
hr 14 RPQSBP 2023-02-08 10:28:52+07 DELTA STREAM 1/1 10m:26s 33MB 16MB 1.00 1/7C030CF0 1/7C030DD8 OK
hr 14 RPQR60 2023-02-08 10:03:52+07 DELTA STREAM 1/1 10m:24s 119kB 16MB 1.00 1/7C030CF0 1/7C030DD8 OK
hr 14 RPQJ7A 2023-02-08 07:14:43+07 FULL STREAM 1/0 13m:22s 3233MB 16MB 2.07 1/7C030CF0 1/7C030DD8 OK
У вас тут одинаковые start и stop lsn. Т.е. не было активности вообще?
hr 14 RPQT69 ---- PAGE ARCHIVE 1/1 5m:3s 0 0 1.00 1/7C030CF0 0/0 ERROR
Не дождался архивации?
Как и что нужно делать в этом случае?
Для работы PITR должна быть настроена архивация логов. У вас логи начинаются 000000010000000100000080.gz . Логов 00000001000000010000007x.gz у вас нет в папке wal. Что вы хотите? Наверняка такие файлы есть в папках pg_wal (pg_xlog?) конкретных бэкапов. Но там будет на момент бэкапа (между start lsn и stop lsn). Вы можете попробовать скопировать их оттуда в папку wal/hr
У вас тут одинаковые start и stop lsn. Т.е. не было активности вообще?
Да. Не было активности вообще. Я об этом и говорю. И WAL не генерились. Тоже вообще. Ни одного. И да, бэкап не дождался архивации, я ж об этом и написал. Не генерируются логи, хотя их архивация настроена.
FULL делались еще когда архивация не была настроена, они в режиме STREAM. Потом я настроил архивацию и сделал DELTA, чтобы бэкап сделался уже при ключенном режиме архивации, и уже следом сделал PAGE.. И восстанавливать я пробую на время между валидными PAGE. Насколько я понимаю, даже для PITR не нужны промежуточные WAL между инкрементными бэкапами? Он же накатывает фулл, потом инкремент, потом следующий инкремент (пропуская накатывание WAL между ними) и WAL начинают уже использоваться при накатывании от последнего использованного инкремента до конкретного момента времени.. Или нет? это подтверждает тот факт, что накатываясь просто на последний инкрементный бэкап (по ID, без PITR), вся цепочка инкрементов отработала нормально..
я пробую восстанавливаться на время 2023-02-08 19:50, это время после инкрементного бэкапа RPRFB4, зачем ему WAL от бэкапов RPR8Q4 и ранее?
hr 14 RPSPCN 2023-02-09 11:19:40+07 PAGE ARCHIVE 1/1 10m:9s 245kB 16MB 1.00 1/840000D8 1/840001C0 OK
hr 14 RPRFB4 2023-02-08 18:45:08+07 PAGE ARCHIVE 1/1 10m:8s 33MB 16MB 1.00 1/83000028 1/83000110 OK
hr 14 RPR8Q4 2023-02-08 16:22:56+07 PAGE ARCHIVE 1/1 10m:8s 245kB 16MB 1.00 1/83000028 1/83000110 OK
Если я просто восстановливаю бэкап по ID:
-i RPSPCN
то все отрабатывает, тоесть, цепочка инкрементов - валидна.. Но проблема в том, что в момент создания бэкапов, не происходит переключений WAL, бэкап не дожидатеся этих переключений, и вот так вот с ворнингом прерывается.. хотя состояние его OK
или я не понял, на что вы хотите указать, или вы не поняли, о чем мой вопрос :)
Уже просматривая все issues подряд, нашел похожий вопрос.. он немного про другое, но в целом, похож на мой..
там тоже отсутствуют необходимые WAL, но у меня они отсутствуют вполне легитимно, так сам postgres работает
postgrespro-1c-14
Логика восстановления PITR при отсутствии необходмых wal https://github.com/postgrespro/pg_probackup/issues/404
я пробую восстанавливаться на время 2023-02-08 19:50
В оригинальном сообщении:
При попытке восстановления на заданное время, возникает ошибка ERROR: Not enough WAL records to time 2023-02-08 00:00:00+07
Вы уверены, что пытаетесь восстановиться на 2023-02-08 19:50 ? Вы приводили пример запускаемых команд валидации, но ни разу не привели пример команды восстановления.
Заметьте, что в команде валидации в ошибке было как раз 19:50
ERROR: Not enough WAL records to time 2023-02-08 19:50:08+07
А время вроде бы (как я вижу в коде) парсится одинаково и для валидации, и для восстановления.
Не может быть такого, что в команду восстановления вы собираете скриптом, и забыли время взять в кавычки? Простите за такое наивное предположение.
Не может быть такого, что в команду восстановления вы собираете скриптом, и забыли время взять в кавычки? Простите за такое наивное предположение.
Вы правы.
Я восстанавливаю через скрипт. И там использую такую конструкцию:
${PGPB_BIN} restore ${PGPB_INSTANCE} -B ${PGPB_DATA} -D "${PG_DATA}" -j 2 ${PG_RECOVERY_PARAMETERS} --remote-proto=none ${PGPB_LOG_SETTINGS}
где PG_RECOVERY_PARAMETERS="--recovery-target-time=\"2023-02-08 19:50:08\""
когда я выполнил из командной строки целиком команду
/usr/bin/pg_probackup-14 restore --instance=hr -B /backup/pg/probackup -D /var/lib/pgpro/1c-14/hr -j 2 --recovery-target-time="2023-02-08 19:50:08" --remote-proto=none --log-level-console=warning --log-level-file=log --log-directory=/var/log/pg_probackup --log-filename=cluster_hr_restore_$(date "+%d-%m-%Y_%H-%M").log
она отработала корректно. Посыпаю голову пеплом.
в свое оправдание, могу сказать лишь, что этот скрипт отрабатывает при этом корректно на другой инсталляции (я его, собственно, и взял уже отлаженный и проверенный с другого сервака). Различия лишь в том, что там, где он работает - Oracle Linux, а вот здесь, где с ним возникли проблемы - Ubuntu..
Более того, когда я смотрел в лог восстановления, которое срубалось с ошибкой, то там первой же записью идет такая строка:
2023-02-09 13:24:21 +07 [2478]: INFO: command: /usr/bin/pg_probackup-14 restore --instance=hr -B /backup/pg/probackup -D /var/lib/pgpro/1c-14/hr -j 2 --recovery-target-time="2023-02-08 19:50:08" --remote-proto
=none --log-level-console=warning --log-level-file=log --log-directory=/var/log/pg_probackup --log-filename=cluster_hr_restore_09-02-2023_13-24.log
обратите внимание, она то как раз корректно "закавычена" :)
--recovery-target-time="2023-02-08 19:50:08"
а вот запись из лога, когда восстановление из командной строки прошло успешно:
2023-02-17 09:27:43 +07 [73623]: INFO: command: /usr/bin/pg_probackup-14 restore --instance=hr -B /backup/pg/probackup -D /var/lib/pgpro/1c-14/hr -j 2 --recovery-target-time=2023-02-08 19:50:08 --remote-proto=
none --log-level-console=warning --log-level-file=log --log-directory=/var/log/pg_probackup --log-filename=cluster_hr_restore_17-02-2023_09-27.log
и вот тут то как раз кавычек нет :)
--recovery-target-time=2023-02-08 19:50:08
я глядел в лог, у меня были подозрения, но, как раз, увидев кавычки я решил, что все верно.
Более того, когда я изначально отлаживал скрипт, я помню, что на некорректно указанный параметр --recovery-target-time (если ошибся в формате даты, или, как раз, напетлял с кавычками) - шла прям явная ругань.. в процессе отладки, как раз, и родилась вышеуказанная конструкция:
PG_RECOVERY_PARAMETERS="--recovery-target-time=\"2023-02-08 19:50:08\""
Так что ваше предположение оказалось полностью верным (включая использование скрипта), видимо, сказался богатый опыт. Так что это я прошу прощения за потраченное время. Благодарю за помощь.
При попытке восстановления на заданное время, возникает ошибка
смотрю при этом, бэкапы PAGE - сделались, со статусом OK, время, на которое восстанавливаюсь, лежит между последним и предпоследним PAGE бэкапами:
проверяю наличие WAL в каталоге бэкапа
прогоняю тестирование:
начинаю разбираться.. в логе бэкапа:
обращаю внимание на вот такие строчки:
подозреваю, что какая-то проблема с WAL.. смотрю, какие WAL создавались в класетере постгри в это время выясняю, что в базе не было никакой активности, следовательно, нет и вообще никаких WAL.. (база тестовая)
в настройках кластера, что касается WAL:
но при этом в документации сказано:
Когда этот параметр (checkpoint_timeout) больше нуля, сервер будет переключаться на новый файл сегмента, если с момента последнего переключения на новый файл прошло заданное время и наблюдалась какая-то активность базы данных, даже если это была просто контрольная точка. (Контрольные точки пропускаются, если в базе отсутствует активность).
следовательно, если нет активности вообще, то не будет и переключения WAL. И тогда бэкапы в режиме PAGE будут вот такими.. как будто бы живыми, но на самом деле - поломанными, чтоли?
Ради проверки, я создал просто запись в таблице, произошло принудительное переключение WAL, он приехал в каталог бэкапов..
Запустил валидацию, она на этот раз прошла успешно (ну а чо, WAL же есть консистентный :))
Это подтвердило мою мысль, что дело в этом, в отстутсвии активности, и как следствие, WAL-ов. Но, при этом, восстанавливаться бэкап все-равно отказался, с той же ошибкой:
Причем, pg_probackup считает при этом всю цепочку бэкапов поломанной, и сообщает, что время, на которое можно восстановиться - вообще от самого первого фулла в цеопчке: 2023-02-07 22:44:33+07
hr 14 RPPVKY 2023-02-07 22:44:33+07 FULL STREAM 1/0 13m:28s 3233MB 16MB 2.07 1/7C030CF0 1/7C030DD8 OK
При этом, если поглядеть, то WAL-файлы то есть:
но, так как они очень редкие, и сделаны не во время выполнения инкрементных бэкапов, то сами бэкапы закончились с ворнингами по таймаутам, и, следовательно, считаются вот такими, хоромыми.. я не знаю, как правильно и последовательно объяснить этот механизм, но думаю, дело как раз в этом, в крайне редком переключении WAL.. Следовательно, PITR восстановление в этом случае не будет отрабатывать. Нужно еще будет проверить, если указать какой-то из PAGE бэкапов директивно, будет ли восстанавливаться успешно по цепочке инкрементов, при отсутствии "промежуточных" WAL между инкрементами..
Оно, вроде, получается, и не баг.. Но поведение какое-то странное. Как и что нужно делать в этом случае? Все бы решило директивное переключение WAL в кластере, но я не нашел настроек, которые бы позволили это сделать при нулевой активности в базе.
Получается, если, например, выходные, никто ничего в базе не поделал, то и бэкапы, которые инкрементные в автоматическом режиме, они тоже будут иметь такой вот статус.. "консистентно-неконсистентный".. И как быть в этом случае..? Ведь любой PITR при этом будет завершаться сбоем и нужно будет каждый раз проводить расследование?