funny-falcon
commented
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
ktulkhu
При попытке восстановления на заданное время, возникает ошибка
смотрю при этом, бэкапы 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 при этом будет завершаться сбоем и нужно будет каждый раз проводить расследование?