Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
 Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Добрый день.
Пока только вникаю в данную тему, пытаюсь освоить теорию. Есть задача обеспечить возможность восстановления любой базы на любой момент времени в течении трех суток. На сервере есть несколько баз. Немного почитав, вроде как инкрементное резервное копирование для этого и предназначено, но с оговоркой что оно работает на весь sql (https://postgrespro.ru/docs/postgresql/10/continuous-archiving). Получается нужно иметь полную копию текущего сервера и если нужно восстановить на какой-то конкретный промежуток, то просто удаляем все WAL от нужного момента времени и запускаем сервер. Ну а после этого уже можем импортировать нужную базу. Заглянув на основной сервер (резервный еще не делал, пока теорию изучаю) я вижу кучу WAL только за сутки и если я правильно понимаю, то все ранние изменения уже применились окончательно. Не могу понять как реализовать возможность отката, скажем на пол часа назад. Можете "ткнуть носом" в документацию, если не сложно?
23 янв 20, 10:22    [22065000]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 974
Для восстановления на заданную метку времени берёте basebackup, снятие которого завершилось до требуемой метки времени восстановления, указываете recovery_target_time, restore_command с командой которая будет тянуть WAL из архива, переводите базу в recovery (если pg12 или новее), запускаете, ждёте и смотрите за логом.
23 янв 20, 12:17    [22065128]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Melkij, Спасибо. Сами WAL могут лежать все в pg_wal Параметром recovery_target_time мы регулируем на какой момент времени восстановить. Надеюсь верно понял.
23 янв 20, 15:45    [22065323]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4071
VitaliyKVN
Melkij, Спасибо. Сами WAL могут лежать все в pg_wal Параметром recovery_target_time мы регулируем на какой момент времени восстановить. Надеюсь верно понял.


НЕТ... вал архив должен лежать ВНЕ базы в архиве wal логов.
23 янв 20, 15:55    [22065336]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Maxim Boguk,
Ясно, спасибо за помощь.
23 янв 20, 17:32    [22065419]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Что-то не выходит восстановление на указанную дату...
Создаю полную копию через pg_basebackup (без остановки).
Разворачиваю сервер с аналогичной версией.
Останавливаю на нем sql , очищаю директорию main, распаковываю в него из архива, выставляю права. Создаю файл recovery.conf с параметром указывающим на папку с файлами WAL, в самом же pg_wal/ и с параметром ecovery_target_time. Копирую в папку WAL файлы из pg_wal/ основного сервера. Примерно за период сутки с момента создания архива.
Запускаю сервер...стартует дольше обычного. Но данные только на момент создания этого архива. То есть параметр ecovery_target_time вроде как не отработал (чтобы в нем я не выставил - данные только на момент создания архива).

Ниже полный лог:

2020-02-20 17:37:00.853 +03 [32524] СООБЩЕНИЕ: для приёма подключений по адресу IPv6 "::1" открыт порт 5432
2020-02-20 17:37:00.853 +03 [32524] СООБЩЕНИЕ: для приёма подключений по адресу IPv4 "127.0.0.1" открыт порт 5432
2020-02-20 17:37:00.856 +03 [32524] СООБЩЕНИЕ: для приёма подключений открыт Unix-сокет "/var/run/postgresql/.s.PGSQL.5432"
2020-02-20 17:37:00.998 +03 [32525] СООБЩЕНИЕ: работа системы БД была прервана; последний момент работы: 2020-02-14 16:22:28 +03
cp: не удалось выполнить stat для '/home/..../WAL/00000002.history': Нет такого файла или каталога
2020-02-20 17:37:01.974 +03 [32525] СООБЩЕНИЕ: начинается восстановление архива
2020-02-20 17:37:02.133 +03 [32525] СООБЩЕНИЕ: файл журнала "000000010000001000000022" восстановлен из архива
2020-02-20 17:37:02.593 +03 [32525] СООБЩЕНИЕ: файл журнала "000000010000001000000020" восстановлен из архива
2020-02-20 17:37:04.120 +03 [32525] СООБЩЕНИЕ: запись REDO начинается со смещения 10/20000028
2020-02-20 17:37:05.571 +03 [32525] СООБЩЕНИЕ: файл журнала "000000010000001000000021" восстановлен из архива
2020-02-20 17:37:09.997 +03 [32525] СООБЩЕНИЕ: файл журнала "000000010000001000000022" восстановлен из архива
2020-02-20 17:37:12.521 +03 [32545] postgres@redmine ВАЖНО: система баз данных запускается
2020-02-20 17:37:12.530 +03 [32546] postgres@redmine ВАЖНО: система баз данных запускается
2020-02-20 17:37:12.693 +03 [32525] СООБЩЕНИЕ: согласованное состояние восстановления достигнуто по смещению 10/22840A18
2020-02-20 17:37:12.694 +03 [32524] СООБЩЕНИЕ: система БД готова к подключениям в режиме "только чтение"
2020-02-20 17:37:12.852 +03 [32525] СООБЩЕНИЕ: файл журнала "000000010000001000000023" восстановлен из архива
2020-02-20 17:37:13.237 +03 [32550] [н/д]@[н/д] СООБЩЕНИЕ: неполный стартовый пакет
2020-02-20 17:37:14.589 +03 [32525] СООБЩЕНИЕ: файл журнала "000000010000001000000024" восстановлен из архива
...............
2020-02-20 17:37:40.333 +03 [32525] СООБЩЕНИЕ: файл журнала "00000001000000100000002C" восстановлен из архива
2020-02-20 17:37:41.592 +03 [32525] СООБЩЕНИЕ: записи REDO обработаны до смещения 10/2CCB62D8
2020-02-20 17:37:41.592 +03 [32525] СООБЩЕНИЕ: последняя завершённая транзакция была выполнена в 2020-02-14 17:02:52.29492+03
2020-02-20 17:37:41.667 +03 [32525] СООБЩЕНИЕ: файл журнала "00000001000000100000002C" восстановлен из архива
cp: не удалось выполнить stat для '/home/...../WAL/00000002.history': Нет такого файла или каталога
2020-02-20 17:37:41.987 +03 [32525] СООБЩЕНИЕ: выбранный ID новой линии времени: 2
2020-02-20 17:37:42.397 +03 [32525] СООБЩЕНИЕ: восстановление архива завершено
cp: не удалось выполнить stat для '/home/...../WAL/00000001.history': Нет такого файла или каталога
2020-02-20 17:37:50.871 +03 [32524] СООБЩЕНИЕ: система БД готова принимать подключения


Явно что-то не так делаю, но не могу уловить.
20 фев 20, 17:43    [22084051]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 974
VitaliyKVN,

приведите целиком ваш recovery.conf
20 фев 20, 18:00    [22084064]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
restore_command = 'cp /home/...../WAL/%f %p'
recovery_target_timeline = 'latest'

Все., остальное закомментировано

Еще пробовал выставлять recovery_target_time = '2020-02-15 00:00:00'
Но в логе появляется строка о том что восстановление на указанное время, однако по факту все аналогично приведенному.

Сейчас повторю тест с датой и временем и приложу.
20 фев 20, 18:12    [22084075]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
2020-02-20 18:18:39.687 +03 [2939] СООБЩЕНИЕ: для приёма подключений по адресу IPv6 "::1" открыт порт 5432
2020-02-20 18:18:39.687 +03 [2939] СООБЩЕНИЕ: для приёма подключений по адресу IPv4 "127.0.0.1" открыт порт 5432
2020-02-20 18:18:39.690 +03 [2939] СООБЩЕНИЕ: для приёма подключений открыт Unix-сокет "/var/run/postgresql/.s.PGSQL.5432"
2020-02-20 18:18:39.777 +03 [2940] СООБЩЕНИЕ: работа системы БД была прервана; последний момент работы: 2020-02-14 16:22:28 +03
cp: не удалось выполнить stat для '/home/....../WAL/00000002.history': Нет такого файла или каталога
2020-02-20 18:18:40.872 +03 [2940] СООБЩЕНИЕ: начинается восстановление точки во времени до 2020-02-17 03:00:00+03
2020-02-20 18:18:40.951 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000022" восстановлен из архива
2020-02-20 18:18:41.700 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000020" восстановлен из архива
2020-02-20 18:18:43.700 +03 [2940] СООБЩЕНИЕ: запись REDO начинается со смещения 10/20000028
2020-02-20 18:18:45.242 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000021" восстановлен из архива
2020-02-20 18:18:47.751 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000022" восстановлен из архива
2020-02-20 18:18:49.975 +03 [2940] СООБЩЕНИЕ: согласованное состояние восстановления достигнуто по смещению 10/22840A18
2020-02-20 18:18:49.976 +03 [2939] СООБЩЕНИЕ: система БД готова к подключениям в режиме "только чтение"
2020-02-20 18:18:50.049 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000023" восстановлен из архива
2020-02-20 18:18:50.486 +03 [2963] [н/д]@[н/д] СООБЩЕНИЕ: неполный стартовый пакет
2020-02-20 18:18:51.520 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000024" восстановлен из архива
2020-02-20 18:18:52.729 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000025" восстановлен из архива
2020-02-20 18:18:53.877 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000026" восстановлен из архива
2020-02-20 18:18:55.733 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000027" восстановлен из архива
2020-02-20 18:18:57.535 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000028" восстановлен из архива
2020-02-20 18:18:58.362 +03 [2940] СООБЩЕНИЕ: файл журнала "000000010000001000000029" восстановлен из архива
2020-02-20 18:18:59.652 +03 [2940] СООБЩЕНИЕ: файл журнала "00000001000000100000002A" восстановлен из архива
2020-02-20 18:19:01.632 +03 [2940] СООБЩЕНИЕ: файл журнала "00000001000000100000002B" восстановлен из архива
2020-02-20 18:19:02.664 +03 [2940] СООБЩЕНИЕ: файл журнала "00000001000000100000002C" восстановлен из архива
2020-02-20 18:19:03.456 +03 [2940] СООБЩЕНИЕ: записи REDO обработаны до смещения 10/2CCB62D8
2020-02-20 18:19:03.456 +03 [2940] СООБЩЕНИЕ: последняя завершённая транзакция была выполнена в 2020-02-14 17:02:52.29492+03
2020-02-20 18:19:03.558 +03 [2940] СООБЩЕНИЕ: файл журнала "00000001000000100000002C" восстановлен из архива
cp: не удалось выполнить stat для '/home/..../WAL/00000002.history': Нет такого файла или каталога
2020-02-20 18:19:03.663 +03 [2940] СООБЩЕНИЕ: выбранный ID новой линии времени: 2
2020-02-20 18:19:03.797 +03 [2940] СООБЩЕНИЕ: восстановление архива завершено
cp: не удалось выполнить stat для '/home/...../WAL/00000001.history': Нет такого файла или каталога
2020-02-20 18:19:11.553 +03 [2939] СООБЩЕНИЕ: система БД готова принимать подключения
20 фев 20, 18:20    [22084086]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Добавил только recovery_target_time = '2020-02-17 03:00:00'
20 фев 20, 18:21    [22084088]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
Guzya
Member

Откуда:
Сообщений: 416
Вы WAL файлы архивируете на основном сервере?
21 фев 20, 10:42    [22084383]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
Guzya
Member

Откуда:
Сообщений: 416
Приведите полностью команду резервного копирования и файл backup_label из резервной копии.
21 фев 20, 10:49    [22084391]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Guzya, Да, все файлы из каталога pg_wal основного сервера скопировал в папку /home/..../WAL
21 фев 20, 12:07    [22084447]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Ну и команда, которой делал полный архив
pg_basebackup -h localhost -U postgres -D /home/....../Arhiv -F t
21 фев 20, 12:14    [22084457]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
Guzya
Member

Откуда:
Сообщений: 416
VitaliyKVN
Guzya, Да, все файлы из каталога pg_wal основного сервера скопировал в папку /home/..../WAL


Это не то.

К моменту, когда Вы захотите развернуть бэкап у Вас в pg_wal уже может не быть нужных файлов.

Архивирование WAL это, когда postgres складывает заполненные\не нужные wal-файлы в отдельное место (для сохранности),
а уже потом удаляет из pg_wal.

Посмотрите команду archive_command.

Найдите файл backup_label в бэкапе, в нем должен быть указан wal-файл с которого этот бэкап может начать восстановление.
Соответственно для восстановления до какой-то точки нужны все wal-файлы от указанного в backup_label до того, который содержит
ту самую точку.
21 фев 20, 12:51    [22084501]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Получается мне на основном сервере нужно обязательно настраивать archive_command? Я же для теста только скопировал файлы начиная чуть раньше начала создания архива и + двое суток. Копию брал с боевого сервера, а перезапуск пока не возможен...
21 фев 20, 13:59    [22084566]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
VitaliyKVN
Member

Откуда:
Сообщений: 11
Guzya, то что нужно будет копировать все файлы wal я понимаю, сейчас пока "учусь" вот и не настраивал постоянное копирование. Меня интересует почему я не могу на указанное время восстановиться, хотя вся цепочка есть....
21 фев 20, 14:41    [22084617]     Ответить | Цитировать Сообщить модератору
 Re: Отказоустойчивость PostgreSQL  [new]
Guzya
Member

Откуда:
Сообщений: 416
Попробуйте положить файлы напрямую в pg_wal (чтобы без restore_command обойтись).
21 фев 20, 15:50    [22084719]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить