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

Откуда: Москва
Сообщений: 169
Коллеги, хотелось бы обсудить с экспертами , все ли правильно делаю для восстановления PITR c помощью штатных средств PostgreSQL

Для непрерывного архивирования WAL использую pg_recievewal (запускается как сервис systemd)
Базовая копия подготавливается с помощью pg_basebackup

Восстановление , по документации (версия 11)
-восстанавливаю кластер из базовой копии
-очищаю папку pg_wal
-переношу файлы WAL из папки хранения архивов в папку pg_wal

Возникает интересный момент - частичный файл .partial
Что с ним делать ?

Я делаю следующим образом :
1) переименовываю файл в стандартный WAL ( mov 0001000005.partial 0001000005 )
2) дополняю нулями до 16МБ (dd ...... )

Для старта БД формирую файл recovery.conf
restore_command = 'cp .../pg_wal/%f  %p'
recovery_target_time = '2020-10-27 08:02:33'
recovery_target_action=promote


Если не указывать строку
recovery_target_action=promote


Восстановление останавливается с сообщением :
log
2020-10-27 08:57:50.189 EDT [21737] LOG: recovery stopping before commit of transaction 576, time 2020-10-27 08:02:46.108794-04
2020-10-27 08:57:50.189 EDT [21737] LOG: recovery has paused
2020-10-27 08:57:50.189 EDT [21737] HINT: Execute pg_wal_replay_resume() to continue.


В случае использования строки recovery_target_action=promote , восстановление заканчивается штатно на заданную точку во времени :
log
2020-10-27 09:33:51.614 EDT [23209] LOG: recovery stopping before commit of transaction 576, time 2020-10-27 08:02:46.108794-04
2020-10-27 09:33:51.614 EDT [23209] LOG: redo done at 0/4004260
2020-10-27 09:33:51.614 EDT [23209] LOG: last completed transaction was at log time 2020-10-27 08:02:11.500505-04
cp: cannot stat ‘/postgres/waldir/00000002.history’: No such file or directory
2020-10-27 09:33:51.621 EDT [23209] LOG: selected new timeline ID: 2
2020-10-27 09:33:51.753 EDT [23209] LOG: archive recovery complete
cp: cannot stat ‘/postgres/waldir/00000001.history’: No such file or directory
2020-10-27 09:33:51.982 EDT [23172] LOG: database system is ready to accept connections

Собственно вопросы к экспертам :
1) Все ли я правильно делаю в данном сценарии
2) Возможно ли как то автоматизировать пункт 2 (дополнение нулями до 16МБ)
28 окт 20, 08:35    [22221892]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
Guzya
Member

Откуда:
Сообщений: 622
По идеи Вам не надо:

-очищаю папку pg_wal
не нужные файлы не трогаются

-переношу файлы WAL из папки хранения архивов в папку pg_wal
делает команда restore_command (руками делать не нужно)

recovery_target_action=promote
говорит, что Вы хотите стартануть postgres, как полноценный самостоятельный сервер.


Т.е. сценарий примерно такой:
восстанавливаетесь из базовой копии
подготавливаете recovery.conf
стартуете postgres
28 окт 20, 10:08    [22221945]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
rinace
Member

Откуда: Москва
Сообщений: 169
Guzya
По идеи Вам не надо:
-переношу файлы WAL из папки хранения архивов в папку pg_wal
делает команда restore_command (руками делать не нужно)

Да, это согласен. Просто тестовый сценарий . В реальности это шаг автоматизируется, согласен.

Но вопрос - что делать с .partial ?
Не дополнить нулями нельзя, будет ошибка.
Не переименовать тоже нельзя. Возможно там временная точка восстановления.
Возможно как то автоматизировать ?

Guzya

recovery_target_action=promote
говорит, что Вы хотите стартануть postgres, как полноценный самостоятельный сервер.

Конечно как полноценный сервер. Это ведь сценарий восстановления после аварии в конфигурации stand-alone

Если не указывать recovery_target_action=promote восстановление останавливается
28 окт 20, 10:49    [22221990]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
Guzya
Member

Откуда:
Сообщений: 622
Если машина с которой льются wal не совсем погибла, можно оттуда взять нужный wal.
28 окт 20, 10:56    [22221997]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
rinace
Member

Откуда: Москва
Сообщений: 169
Guzya,

предполагается , что машина погибла полностью.
В наличии только базовая РК и архивные файлы WAL
28 окт 20, 10:58    [22222001]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
Guzya
Member

Откуда:
Сообщений: 622
по поводу автоматизации дополнения нулями
28 окт 20, 10:59    [22222006]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
rinace
Member

Откуда: Москва
Сообщений: 169
Guzya,

именно эту ссылку и использовал, но там считать цифры надо ручками
автор
for example using
28 окт 20, 11:02    [22222011]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
Guzya
Member

Откуда:
Сообщений: 622
примерный код

walsize=16777216  # эталонный размер
filesize=$(stat -c%s "test.partial")   # текущий размер файла

raznica=$( expr $walsize - $filesize )  # считаем сколько не хватает

dd if=/dev/zero of=test.partial oflag=append conv=notrunc bs=1 count=$raznica  # дописываем


Тут dd будет долго думать потому что будем писать много по одному байту.
По хорошему надо сделать в два захода dd, первый пишет по bs=1024 count=целочисленное деление ($raznica/1024)
а второй по bs=1 count=остаток от деления $raznica/1024
28 окт 20, 12:32    [22222108]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
rinace,

Я бы сказал что у вас по 1) все верно а вот на счет 2) возникают вопросы откуда вообще возникла такая задача.

Потому что если требуется оперативный failover на текущее состояние после отказа мастера - для этого нужна реплика (hot standby) а не base backup + wal archive.

Base backup + wal archive используется в случае когда надо восстановиться на какую то точку в прошлом, а если точка в прошлом то вопрос что делать с .partial - он не критичен потому что этот файл не требуется для решения задачи.

Т.е. с моей точки зрения вопрос 2 возник потому что вы пытаетесь решить задачу не подходящими (и не предназначенными) для этого средствами.
И ответ на вопрос два будет "не делайте так".

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
28 окт 20, 12:48    [22222124]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
rinace
Member

Откуда: Москва
Сообщений: 169
Maxim Boguk,

Постановка задачи стандартная :
1) Есть сервер БД stand-alone.
2) Нужно обеспечить резервное копирование и восстановление на точку во времени штатными средствами из коробки.

Зачем нужно восстановление на момент времени ?
Ну хотя бы для развертывания тестовой базы .
28 окт 20, 12:52    [22222130]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
Guzya
Member

Откуда:
Сообщений: 622
walsize=16777216  # эталонный размер
filesize=$(stat -c%s "test.partial")   # текущий размер файла

raznica=$( expr $walsize - $filesize )  # считаем сколько не хватает
blok_1024=$( expr $raznica / 1024 )
blok_1=$( expr $raznica % 1024 )

if [[ $blok_1024 -gt 0 ]]; then
    dd if=/dev/zero of=test.partial oflag=append conv=notrunc bs=1024 count=$blok_1024  # дописываем по 1024 байта
fi

if [[ $blok_1 -gt 0 ]]; then
    dd if=/dev/zero of=test.partial oflag=append conv=notrunc bs=1 count=$blok_1  # дописываем по 1 байту
fi
28 окт 20, 12:58    [22222140]     Ответить | Цитировать Сообщить модератору
 Re: PITR - сценарий. Вопрос к экспертам.  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
rinace
Maxim Boguk,

Постановка задачи стандартная :
1) Есть сервер БД stand-alone.
2) Нужно обеспечить резервное копирование и восстановление на точку во времени штатными средствами из коробки.

Зачем нужно восстановление на момент времени ?
Ну хотя бы для развертывания тестовой базы .


Ну вот сочетание 1+2 оно из категории задач "не делайте так", я понимаю что всякое бывает в жизни но лучше объяснить заказчику что так не надо делать. Потому что например потом быстро вылезет вопрос - а почем восстановление после сбоя stand-alone мастера занимает 5 часов (а то и 20+ часов, у меня рекорд 63 часа на восстановление из base backup 3х дневной давности и wal_archive).
Восстановление на точку времени - да нормально, оперативный failover без (с минимальной) потерей транзакций - нет не нормально.

А вот для развертывания тестовой базы - потеря тех транзакций что были в .partial - не критична (я не могу придумать сценарий когда это было бы критично).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
28 окт 20, 13:05    [22222152]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить