Comments 13
Тема очень интересная, но статья явно не полная. Добавили бы побольше примеров. Возможно, ссылки на документацию или какие-то похожие статьи.
По одному вашему описанию не разобраться, а вектор для дальнейшего изучения как то плохо задали.
Код мельком посмотрел — на своей базе без тщательного изучения не стал бы запускать.
По одному вашему описанию не разобраться, а вектор для дальнейшего изучения как то плохо задали.
Код мельком посмотрел — на своей базе без тщательного изучения не стал бы запускать.
Я вот в репликации постгреса никак не могу принять одну вещь: то, что на мастере в команде архивирования надо указывать путь к папке на реплике, чтобы мастер туда складывал wal-файлы на время активного pg_base_backup при первоначальной «наливке» реплики (когда идет rsync с мастера, например). Это ломает всю концепцию — мастер должен что-то знать о реплике (репликах).
Можно, конечно, и не настраивать архивирование; а просто увеличить кол-во хранимых «живых» wal-файлов и rsync-ать их уже после выполнения pg_stop_backup, но в этом случае увеличивается риск того, wal-файлы отротируются раньше, чем закончится rsync наливки реплики. Да и последующий rsync wal-файлов после pg_stop_backup будет лишнее время занимать, ведь начнут копироваться уже устаревшие wal-файлы (коих большинство).
Ну почему, почему они не сделали так, что после выполнения pg_start_backup можно было спокойно rsync-ать файлы базы без единого wal-файла, а wal-файлы сами бы потом подтягивались через протокол репликации? Это бы значительно упростило наливку реплики (которую приходится делать каждый раз, когда падает мастер, при условии, что реплик несколько, а не одна).
Можно, конечно, и не настраивать архивирование; а просто увеличить кол-во хранимых «живых» wal-файлов и rsync-ать их уже после выполнения pg_stop_backup, но в этом случае увеличивается риск того, wal-файлы отротируются раньше, чем закончится rsync наливки реплики. Да и последующий rsync wal-файлов после pg_stop_backup будет лишнее время занимать, ведь начнут копироваться уже устаревшие wal-файлы (коих большинство).
Ну почему, почему они не сделали так, что после выполнения pg_start_backup можно было спокойно rsync-ать файлы базы без единого wal-файла, а wal-файлы сами бы потом подтягивались через протокол репликации? Это бы значительно упростило наливку реплики (которую приходится делать каждый раз, когда падает мастер, при условии, что реплик несколько, а не одна).
>> на мастере в команде архивирования надо указывать путь к папке на реплике, чтобы мастер туда складывал wal-файлы на время активного pg_base_backup при первоначальной «наливке» реплики
Необязательно складывать архивы на реплику. Можно складывать локально, а потом на слейве указать restore_command = 'scp user@master:/path/to/archive/%f "%p"'. Пусть берет их по сети.
Необязательно складывать архивы на реплику. Можно складывать локально, а потом на слейве указать restore_command = 'scp user@master:/path/to/archive/%f "%p"'. Пусть берет их по сети.
> Однако этот вариант не предлагает восстановить каталог базы данных на момент предшествующий сбою, алишь на момент выполнения бэкапа.
Если речь о некорректных миграциях, то достаточно делать бэкапы непосредственно перед ними, а не (только) по крону.
Если речь о некорректных миграциях, то достаточно делать бэкапы непосредственно перед ними, а не (только) по крону.
эх… мне бы ваш оптимизм…
на базах размером в несколько тер, с тысячами схем и миллионами файлов в каталогах, под нагрузкой, все не так уж и радужно.
на базах размером в несколько тер, с тысячами схем и миллионами файлов в каталогах, под нагрузкой, все не так уж и радужно.
Для фанатов — вышла недавно книжкаhow-to на 40 страниц Instant PostgreSQL Backup and Restore How-to. В ней подробно описываются все возможные способы бэкапа и восстановления из него со всеми плюсами и минусами.
postgresql.leopard.in.ua/ — 10 глава. На проектах я использую часто wal-e, при этом настроены slave сервера, что читают не с мастера, а с s3 бекапов.
Sign up to leave a comment.
Резервное копирование и восстановление в PostgreSQL