Назад | Перейти на главную страницу

Синхронная многомастерная репликация postgresql pgpool 2

Мы хотели бы построить систему из двух серверов Postgresql 8.4 с pgpool 2 впереди, чтобы все операции записи шли в обе системы. В случае сбоя на одном из узлов он выйдет из строя, и pgpool направит все операции записи на оставшийся узел.

Оттуда мы можем вручную повторно синхронизировать все и вернуть все обратно.

В настоящее время я провожу некоторое тестирование этого эффекта и замечаю некоторые интересные вещи.

В моем сценарии есть простой цикл, который вставляет строки в базу данных. Когда я выключаю сетевой интерфейс на одном сервере, сценарий приостанавливается, pgpool ждет ответа от отключенного сервера, но не ухудшает его, пока кто-то другой не попытается подключиться. Как только кто-то другой создаст новое соединение, он вернет ошибку и ухудшит работу сервера. Затем, если я снова запустил сценарий, он направит запись на единственный оставшийся сервер.

Это похоже на слишком большую активность, необходимую для ухудшения состояния сервера. Я что-то упускаю? это нормально?

Ура

отметка

Я считаю, что поведение, которое вы описываете, является нормальным для pgpool - оно ухудшает работу сервера, когда он не может подключиться к нему, но если соединение уже «установлено», оно не умирает так быстро, как вы могли ожидать (это, вероятно, устранять временные сбои в сети и избегать ухудшения среды из-за «сбоев»).


Из любопытства, рассматривали ли вы репликацию потокового журнала, доступную в Postgres 9? Последняя реализация работает почти в реальном времени и позволяет выполнять запросы на подчиненных серверах. Я считаю, что синхронная репликация скоро появится (или, возможно, уже реализована).
Вам понадобится сценарий или ручной процесс для обработки сбоя (перезапустите один из «подчиненных» серверов в качестве главного и переместите виртуальный IP-адрес), но в остальном реализация существенно не отличается от того, что вы получите из pgpool (re -sync при сбое сервера и т. д.)

Большим преимуществом здесь является то, что вы используете то, что встроено в ядро ​​сервера Postgres, и оно прошло довольно обширное тестирование и документирование в процессе бета-версии 9.0. Это моя рекомендация де-факто, если у вас нет ограничений, делающих это непрактичным.