Какое решение для репликации PostgreSQL использовать для моего конкретного сценария

Question

Мне нужно скопировать сервер базы данных PostgreSQL следующим образом:

1. Два сервера находятся рядом друг с другом - один является главным, а другой - резервным. Если мастер отказывает, резервное управление вступает во владение. Репликация от главного к подчиненному должна быть отказоустойчивой, следовательно, синхронной. Резерв не будет использоваться для каких-либо запросов, если он не стал мастером. Таким образом, высокая доступность / балансировка нагрузки не требуется.

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

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

Самое близкое, что я придумал, - это использование pgpool-II для сценария 1 и Mammoth для сценария 2. Однако, поскольку pgpool основан на операторах, что произойдет с запросами, содержащими rand () и now ()?

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

Кроме того, только побочный вопрос - в соответствии со сценарием 1 выше, когда мастер отказывает, резервный режим вступает во владение. Будет ли после этого отменена роль главного-подчиненного или после восстановления главного сервера ведомый вернется в состояние ожидания?

Любое предложение будет высоко оценено. Спасибо.

Answer 1

Я предлагаю использовать DRBD для сценария 1 и встроенную репликацию 9.0 или Slony для сценария 2.

До выпуска PostgreSQL 9.1 (еще не выпущенного) не было другого доступного решения для синхронной репликации, и DRBD широко используется для этой цели. Вместе с Pacemaker или Heartbeat, которые поставляются со всеми сценариями, необходимыми для мониторинга и переключения PostgreSQL, у вас есть очень надежное и довольно простое в управлении решение. (На самом деле, я бы хотел продолжить использовать DRBD даже после выхода 9.1; это намного проще и имеет более продолжительный послужной список.)

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

Answer 2

Вы не упомянули, был ли рассматриваемый сервер установлен на определенную версию или это был новый проект со свободой выбора версии. Ответы различаются в зависимости от этой информации.

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

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

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

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

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