бекап при потоковой репликации

Добрый день, у меня 2 сервера postgresql. Один рабочий, второй резервный, они находятся в режиме потоковой репликации. Так вот, из-за снижения производительности при выполнении бекапа (pg_dump) на рабочем, я решил перенсти эту задачу на резервный сервер. До этого пробовал играться с утилитами cpulimit, nice и ionice, не помогло( Дамп вообще выполниться не мог.

Хотелось бы просто получить совет, хорошая это идея, делать бекап с резервного сервера (он иногда получается неполный, причину пока что не выяснил) или можно вообще отказаться от выполнения бекапа при наличии потоковой репликации?

gk2,

Бекап != Реплика. Первое правило админа.

Что значит не полный?.. Данные будут там с некоторым опозданием. Если-же он не консистентный, то вопрос к разработчику приложения, БД - почему не использовал ссылки, транзакции.

gk2,

http://www.postgresql.org/message-id/548AF1CB.80702@vmware.com

вот так еще. есть стриминг -- теряем архив при переключении.
надо писать как-то в архив со стендбая, если хотим не терять.

Warstone
gk2, Бекап != Реплика. Первое правило админа.

А что это значит? Можно по подробней.

Electric200,

Я бы сказал, что реплика != бэкап.

Самый простой случай: кто-то грохнул таблицу, не сказал/не заметили/ступили — изменения среплицировались.
В таком случае если не бэкапа — привет!

Electric200,

Если очень коротко, то у резервной копии и реплики разные цели. Их пересечение весьма условно. Значит к ним предъявляются разные требования.

/\/\/\/\/\/\
Electric200, Если очень коротко, то у резервной копии и реплики разные цели. Их пересечение весьма условно. Значит к ним предъявляются разные требования.

Ну подождите. В 8 из 10 преимуществ (всяких книжек и статей) реплики, является возможность снятия бекапа без влияния на мастер. Т.е врут выходит?

Electric200,

Скорее добросовестно заблуждаются.

Резервная копия необходима для восстановления БД при сбое по состоянию на определенный момент. Ничего другого она не делает.

Реплика чаще всего служит для создания "дешевой копии" данных в ситуации при которой использование "настоящего" сервера технически затруднено или не оправдано. На реплике не обязательно имеются все данные с мастера, вполне может быть временная задержка. Так же реплика может иметь существенные ограничения на выполняемые действия.
Сняв резервную копию с реплики, вы получите резервную копию именно реплики.

Electric200
/\/\/\/\/\/\ Electric200, Если очень коротко, то у резервной копии и реплики разные цели. Их пересечение весьма условно. Значит к ним предъявляются разные требования. Ну подождите. В 8 из 10 преимуществ (всяких книжек и статей) реплики, является возможность снятия бекапа без влияния на мастер. Т.е врут выходит?

Если делать pg_basebackup с реплики и у вас версия 9.3+ - тогда вы правы и можно снимать backup с реплики.
Но при снятии pg_basebackup ответственность за то что реплика не отстает на неделю - только на вас да.

Нормально делать pg_dump c реплики которая обслуживает клиентские запросы скорее всего не получится.
Или pg_dump будет прерываться по конфликту с репликацией, или репликация будет останавливаться на время pg_dump, или если ни то ни другое - это начнет аффектить мастер (если включить hotstandby_feedback на реплике).


--Maxim Boguk
www.postgresql-consulting.ru

Maxim Boguk
Если делать pg_basebackup с реплики и у вас версия 9.3+ - тогда вы правы и можно снимать backup с реплики. Но при снятии pg_basebackup ответственность за то что реплика не отстает на неделю - только на вас да.

Можно ли, сделав pg_basebackup со слейва, сохранять на созданном кластере wal файлы, поступающие с master? Вроде бы можно, и это удобно.

А вот сделать снепшот на нужную дату, а потом раз в день проигрывать wal файлы - нельзя.
Нужно каждый раз делать pg_basebackup. Досадно..