Потоковая репликация и отработка отказа в PostgreSQL


14

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

Доступны различные решения:

  1. Repmgr
  2. Linux Heartbeat
  3. Pgpool-II (только для автоматического перехода на другой ресурс)
  4. Любой другой инструмент, если вы использовали.

Мой вопрос: какое решение следует использовать?

Ответы:


8

В нашем магазине мы выбрали repmgr и pgbouncer вместо pgpool. У repmgr есть несколько хороших инструментов для настройки и обслуживания кластера реплицированных серверов баз данных. В нашем случае 1 мастер и 2 подчиненных (один отказоустойчивый и один тест производительности чтения в реальном времени, который может стать восстановлением после отказа нового главного устройства). У pgpool есть проблемы с изменениями в конфигурации, в большинстве случаев вам нужно перезапустить службу, и поэтому у вас есть некоторое время простоя. Это проблема, когда вам нужна доступность 24x7x365.

repmgrd (deamon) помогает выбрать нового мастера после перехода на другой ресурс, вам действительно не нужна ситуация с раздвоенным мозгом. У нас есть один виртуальный IP-адрес для главной базы данных, базы данных, которая является главной на тот момент. Когда другой сервер становится главным, это единственный сервер, использующий этот адрес. Каждый сервер базы данных также имеет свой собственный IP-адрес для запросов только для чтения.

repmgr поддерживается теми же парнями, которые изначально создавали потоковую репликацию, поэтому они знают, о чем говорят. Версия 2.0 скоро будет выпущена.

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

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


1

Мы используем два разных решения одновременно ...

Pgpool-II для синхронной репликации и Slony2 для асинхронной (запускаемой) репликации.

Производительность отличная


Спасибо за ответ ... На самом деле я пытаюсь Pgpool-II с потоковой репликацией. Это обеспечивает автоматический переход на другой ресурс. Но если я снова запущу основной узел, может ли pgpool-II снова стать главным или резервным узлом?
Саураб

Насколько я знаю, определенно нет. вам нужно будет выполнить восстановление основного узла вручную. Наша установка немного отличается. это многоуровневая среда, и все узлы имеют равные права. Если один узел не синхронизирован, балансировщики нагрузки отказываются перенаправлять клиентов на этот узел.
user5701
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.