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

Question

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

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

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

Мой план:

1. Настройка архивации WAL на главной БД
2. Создание полного снимка БД и его копирование в удаленное местоположение
3. Восстановите БД и поймайте ее
4. Перейдите в устойчивое состояние, где:
   • ДЕНЬ - БД отстает, но люди могут запросить ее
   • НОЧЬ - Я копирую стоимость дняФайлы WAL и получение базы данных

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

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

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

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

спасибо!

--S

Answer 1

Ваш план должен сработать.
Как говорит Чарльз, теплое резервирование - это еще одно возможное решение.Он поддерживается начиная с версии 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_com, которая ожидает, как описано ранее (см. Раздел 24.3.3).

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

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

Postgres Wiki о теплом режиме ожидания

Настройка блога «Теплый режим ожидания»

Answer 2

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

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

---

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