Последовательное восстановление бэкапов 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

Новые блоги и статьи Все статьи Все блоги /
Использование кэша Laravel - полный гайд bytestream 18.02.2025 Кэширование - один из наиболее эффективных способов повышения производительности веб-приложений. В современном мире, где скорость загрузки страниц напрямую влияет на удержание пользователей и. . .	Создаем REST API в Laravel с аутентификацией через Passport bytestream 18.02.2025 Разработка современных веб-приложений все чаще требует создания надежного и хорошо структурированного API. REST API стал стандартом де-факто для построения взаимодействия между клиентской и серверной. . .	Пайплайны в Laravel - полный гайд bytestream 18.02.2025 Разработка современных веб-приложений часто требует обработки сложных процессов, состоящих из множества последовательных шагов. Например, при создании системы комментариев может потребоваться. . .	Как правильно использовать @required в Symfony bytestream 18.02.2025 При разработке приложений на Symfony мы часто сталкиваемся с необходимостью внедрения зависимостей. Фреймворк предоставляет несколько способов управления этим процессом, и одним из таких инструментов. . .	Система безопасности в Laravel: возможности и примеры Wired 18.02.2025 Каждый день появляются новые виды атак и уязвимостей, которые могут поставить под угрозу конфиденциальные данные пользователей и функционирование всей системы. В этом контексте выбор надежного. . .
Давайте сравним Django и Laravel Wired 18.02.2025 Django и Laravel - два мощных инструмента, которые часто сравнивают между собой. Оба фреймворка предлагают разработчикам богатый набор возможностей для создания масштабируемых веб-приложений, но. . .	Laravel или React - что лучше? Wired 18.02.2025 В разработке веб выбор правильного инструмента часто определяет успех всего проекта. Особенно интересным представляется сравнение Laravel и React - двух популярных технологий, которые часто. . .	Laravel 11: новые возможности, гайд по обновлению Wired 18.02.2025 Laravel 11 - это новая масштабная версия одного из самых популярных PHP-фреймворков, выпущенная в марте 2024 года. Эта версия продолжает традицию внедрения передовых технологий и методологий. . .	Миграции в Laravel Wired 18.02.2025 Разработка веб-приложений на Laravel неразрывно связана с управлением структурой базы данных. При работе над проектом часто возникает необходимость вносить изменения в схему базы данных - добавлять. . .	Аутентификация в Laravel Wired 18.02.2025 В современном мире веб-разработки безопасность пользовательских данных становится критически важным аспектом любого приложения. Laravel, как один из самых популярных PHP-фреймворков, предоставляет. . .

@grgdvo 1256 / 972 / 382 Регистрация: 02.09.2012 Сообщений: 2,998
	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

	07.12.2023, 09:47