Запуск pg_dump на сервере горячего резервирования?

Отказ от ответственности: по общему признанию я еще не пробовал это, но я не уверен, что буду знать, работает ли это неправильно, поэтому я хотел спросить.

Я хотел бы запустить задание ночного резервного копирования (через pg_dumpall) с сервера горячего резервирования, на котором выполняется потоковая репликация, чтобы избежать нагрузки на основной сервер. Я видел только упоминания о некоторых людях, с которыми сталкивались, например, здесь и здесь , но очень мало указаний. Ничего страшного, если резервное копирование немного отстает от основного, если оно совместимо (что и должно быть).

Мои вопросы:

1. Я действительно хочу сделать это, или резервное копирование должно быть сделано на основном сервере? Зачем?

2. При выполнении дампа в режиме ожидания, какие настройки мне нужны и какую процедуру мне следует использовать, чтобы сделать это правильно? например, я должен остановить репликацию на время резервного копирования?

AFAIK, работающий pg_dumpв режиме горячего резервирования, является одной из главных вещей, для которой резервные системы полезны. Это совершенно безопасно, хотя и не совсем надежно - дампы могут потерпеть неудачу, если резервный сервер прерывает транзакцию, когда она слишком сильно отстает от мастера.

Единственное, что вам действительно нужно наблюдать, - это убедиться, что режим ожидания актуален и продолжает работать. Если резервный компьютер потерял связь с мастером и слишком сильно отстал, вам не нужно весело резервировать трехнедельный устаревший резерв.

Вам нужно будет позволить резервному устройству довольно сильно отставать от мастера во время резервного копирования, так как в противном случае ему придется отменить pg_dumpтранзакцию, чтобы продолжить воспроизведение WAL. Смотрите документацию по горячему резервированию , в частности , в раздел «Обработку конфликтов запросов», а max_standby_archive_delayи max_standby_streaming_delayпараметры.

Обратите внимание, что мастер должен быть готов хранить достаточно архивов WAL, чтобы подчиненный мог снова его догнать.

1. Мы делаем резервное копирование в режиме ожидания, это прекрасно.
2. Чтобы избежать конфликта отмененных операторов во время резервного копирования в резервной системе, необходимо приостановить репликацию в резервном режиме SELECT pg_xlog_replay_pause();, а затем запустить резервное копирование, как только оно завершится, SELECT pg_xlog_replay_resume();для возобновления репликации. Имейте в виду, что выполнение вышеуказанных команд приведет к задержке восстановления на ведомом устройстве, которая может быть довольно большой, в зависимости от размера базы данных. Кроме того, примите во внимание пространство, занимаемое сегментами WAL, поскольку они не будут воспроизводиться на ведомом во время паузы.

Вы можете найти некоторые другие полезные административные функции в документации . Например, проверить , если сервер на самом деле в процессе восстановления, до приостановки его: SELECT pg_is_in_recovery().

Если вы приостановите репликацию во время резервного копирования (это хорошая идея для сохранения целостности и согласованности), вы можете отредактировать некоторые строки в своем основном postgresql:

Сколько времени обычно задерживает вашу резервную копию. Убедитесь, что главный узел сохраняет все файлы x_log, необходимые для возобновления репликации. Вы можете сделать это в редактировании postgresql.conf

wal_keep_segments = 32      # in logfile segments, 16MB each; 0 disables

Если вы не изменяете это и процесс резервного копирования слишком длинный, возможно, главный узел удаляет файлы xlog перед отправкой их на ведомое устройство.