Последовательное восстановление бэкапов WAL

@Gefest86 · Регистрация: 07.12.2023

Author24 — интернет-сервис помощи студентам

Здравствуйте. Есть рабочий сервер debian 10 + postgresql 9.6, на нем настроена архивация через pg_basebackup и архивацию wal (wal_level = archive). Есть тестовый сервер, на нем я восстанавливаю бэкап до определенной точки через указание recovery_target_time в recovery.conf.
Допустим, я восстановил базу на 1 число, все восстановилось нормально. Затем я хочу накатить журналы до 2-ого числа. Указываю новый recovery_target_time в recovery.conf, при запуске получаю сообщения вида (архив журналов сжат zstd):

Bash

1	zstd: can't stat /mnt/archive/xlog/0000000200007B0D00000038.zst : No such file or directory -- ignored

Судя по цифре 2 в наименовании файла, сервер пытается восстановить новую временную линию, возникшую после восстановления бэкапа.
Я указываю явно первую временную линию через параметр recovery_target_timeline. В этом случае получаю циклически сообщения:

Bash

1
2
3

2023-12-07 12:16:52.811 +07 [14650] СООБЩЕНИЕ:  файл журнала "0000000100007B0D00000038" восстановлен из архива
2023-12-07 12:16:52.820 +07 [14650] СООБЩЕНИЕ:  по смещению 7B0D/38000028 запрошено продолжение записи
2023-12-07 12:16:53.709 +07 [14666] postgres@postgres ВАЖНО:  система баз данных запускается

Подскажите, как накатить на восстановленную базу новую порцию журналов, или это невозможно?

@grgdvo · 11.12.2023, 22:48

(9.6 - как давно это было...)
При восстановлении бакапа сервер автоматически переводится на новую линию времени. Это by-design со времен старых версий.

The ability to restore the database to a previous point in time creates some complexities that are akin to science-fiction stories about time travel and parallel universes. For example, in the original history of the database, suppose you dropped a critical table at 5:15PM on Tuesday evening, but didn't realize your mistake until Wednesday noon. Unfazed, you get out your backup, restore to the point-in-time 5:14PM Tuesday evening, and are up and running. In this history of the database universe, you never dropped the table. But suppose you later realize this wasn't such a great idea, and would like to return to sometime Wednesday morning in the original history. You won't be able to if, while your database was up-and-running, it overwrote some of the WAL segment files that led up to the time you now wish you could get back to. Thus, to avoid this, you need to distinguish the series of WAL records generated after you've done a point-in-time recovery from those that were generated in the original database history.

To deal with this problem, PostgreSQL has a notion of timelines. Whenever an archive recovery completes, a new timeline is created to identify the series of WAL records generated after that recovery.

https://www.postgresql.org/doc... iving.html

Соответственно не получится накатить. Придется делать новое восстановление и новую recovery_taget_time

@grgdvo 1251 / 967 / 382 Регистрация: 02.09.2012 Сообщений: 2,989
	11.12.2023, 22:48	2
	(9.6 - как давно это было...) При восстановлении бакапа сервер автоматически переводится на новую линию времени. Это by-design со времен старых версий. The ability to restore the database to a previous point in time creates some complexities that are akin to science-fiction stories about time travel and parallel universes. For example, in the original history of the database, suppose you dropped a critical table at 5:15PM on Tuesday evening, but didn't realize your mistake until Wednesday noon. Unfazed, you get out your backup, restore to the point-in-time 5:14PM Tuesday evening, and are up and running. In this history of the database universe, you never dropped the table. But suppose you later realize this wasn't such a great idea, and would like to return to sometime Wednesday morning in the original history. You won't be able to if, while your database was up-and-running, it overwrote some of the WAL segment files that led up to the time you now wish you could get back to. Thus, to avoid this, you need to distinguish the series of WAL records generated after you've done a point-in-time recovery from those that were generated in the original database history. To deal with this problem, PostgreSQL has a notion of timelines. Whenever an archive recovery completes, a new timeline is created to identify the series of WAL records generated after that recovery. https://www.postgresql.org/doc... iving.html Соответственно не получится накатить. Придется делать новое восстановление и новую recovery_taget_time 0