PostgreSQL — использование доставки журналов для постепенного обновления удаленного ведомого устройства только для чтения

Сайт моей компании использует базу данных PostgreSQL. В нашем центре обработки данных у нас есть главная БД и несколько подчиненных БД только для чтения, и мы используем Londiste для непрерывной репликации между ними.

Я хотел бы настроить другую подчиненную БД только для чтения для целей отчетности, и я хотел бы, чтобы эта подчиненная база данных находилась в удаленном месте (за пределами центра обработки данных). Это подчиненное устройство не должно быть на 100% обновленным. Если это до 24 часов, это нормально. Кроме того, я хотел бы свести к минимуму нагрузку на главную БД. Поскольку наша главная БД занята днем ​​и простаивает ночью, я считаю хорошей идеей (если возможно) заставлять отчетный ведомый догонять один раз каждую ночь.

Я думаю об использовании доставки журналов для этого, как описано на http://www.postgresql.org/docs/8.4/static/continuous-archiving.html

Мой план:

  1. Setup WAL archiving on the master DB
  2. Produce a full DB snapshot and copy it to the remote location
  3. Restore the DB and get it caught up
  4. Go into steady state where:
    • DAYTIME -- the DB falls behind but people can query it
    • NIGHT -- I copy over the day's worth of WAL files and get the DB caught up

Примечание: главное здесь то, что мне нужно только один раз скопировать полный моментальный снимок БД. После этого мне нужно будет только скопировать дневные файлы WAL, чтобы снова догнать удаленное ведомое устройство.

Поскольку я еще не занимался доставкой журналов, я хотел бы получить отзыв / совет.

Будет ли это работать? Поддерживает ли PostgreSQL такое повторное восстановление?

Есть ли у вас другие предложения по настройке удаленного полусвежего подчиненного устройства только для чтения?

Спасибо!

--S


postgresql replication log-shipping
person Shahaf    schedule 28.01.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Ваш план должен сработать.
По словам Чарльза, еще одним возможным решением является резервирование в горячем режиме. Он поддерживается, начиная с версии 8.2, и имеет относительно небольшое влияние на производительность основного сервера. Теплый резерв описан в Руководстве: Теплый резерв PostgreSQL 8.4

Краткая процедура настройки резервного сервера выглядит следующим образом. Подробную информацию о каждом шаге см. в предыдущих разделах.

  1. Настройте основную и резервную системы максимально одинаково, включая две идентичные копии PostgreSQL с одинаковым уровнем выпуска.
  2. Настройте непрерывную архивацию с основного на WAL-архив, расположенный в каталоге на резервном сервере. Убедитесь, что на первичном сервере правильно установлены параметры archive_mode, archive_command и archive_timeout (см. Раздел 24.3.1).
  3. Сделайте базовую резервную копию основного сервера (см. Раздел 24.3.2) и загрузите эти данные на резервный.
  4. Начните восстановление на резервном сервере из локального архива WAL, используя файл recovery.conf, в котором указана команда restore_command, ожидающая, как описано ранее (см. Раздел 24.3.3).

Чтобы добиться только ночной синхронизации, ваша команда archive_command должна выходить с ненулевым статусом выхода в дневное время.

Дополнительная информация:

Вики Postgres о горячем резервировании

Настройка горячего резерва публикации в блоге

person johnbaum    schedule 28.01.2011
comment
Теплый резерв не позволяет запрашивать ведомое устройство, для чего требуется версия 9.0. - person Magnus Hagander; 29.01.2011

arrow_upward
3
arrow_downward

встроенная в 9.0 потоковая репликация WAL предназначен для выполнения того, что должно соответствовать вашим целям, — горячего или горячего резерва, который может принимать запросы только для чтения. Вы рассматривали возможность его использования или пока застряли на 8.4?

(Кроме того, предстоящий выпуск 9.1, как ожидается, будет включать обновленную/переписанную версию pg_basebackup, инструмент для создания начальной точки резервного копирования для нового ведомого устройства.)

Обновление: PostgreSQL 9.1 будет включать возможность приостанавливать и возобновлять потоковую репликацию с помощью простого вызова функции на ведомом устройстве.

person Charles    schedule 28.01.2011
comment
Зачем потоковая репликация? Согласно вашей ссылке, его цель - позволить резервному серверу оставаться в более актуальном состоянии, чем это возможно при доставке журналов на основе файлов. - person johnbaum; 28.01.2011
comment
Спасибо за помощь! Вероятно, со временем мы перейдем на потоковую репликацию 9.0 — нам нужно дождаться удобного времени, чтобы сделать это. В то же время мы специально предпочитаем не использовать систему репликации в реальном времени для нашего удаленного подчиненного устройства (например, Slony или Londiste), потому что мы обеспокоены тем, что в случае сбоя соединения с удаленным подчиненным в главной БД может накопиться огромное количество -be-replicated записи на это недоступное подчиненное устройство (мы видели, как это происходит, это нехорошо). При доставке журналов, если ведомое устройство не поспевает за ним, это очень плохо (но это не будет чрезмерно нагружать ведущее устройство). - person Shahaf; 28.01.2011
comment
@Shahaf: Мое понимание потоковой передачи WAL заключается в том, что ее можно приостановить и возобновить в любое время (вручную или иным образом), пока файлы WAL все еще существуют, и эта потоковая передача не является высоконагруженной операцией. - person Charles; 29.01.2011
comment
Вы можете использовать горячую резервную часть 9.0 с доставкой журналов на основе файлов, как и раньше — это функция, отличная от потоковой репликации (хотя они очень хорошо работают вместе). - person Magnus Hagander; 29.01.2011
comment
@Shahaf, я обновил свой пост несколькими интересными новостями о новой функции 9.1, которая кажется вам подходящей. :) - person Charles; 10.02.2011