Отработка отказа Postgresql 9.2

Я настроил потоковую репликацию из главной БД в подчиненную БД. Если главный выключен, подчиненный вступит во владение. Репликация и отработка отказа работают нормально.

У меня есть веб-приложение, использующее основную базу данных для хранения данных.

Некоторые подробности:

  • Оба сервера работают под управлением Centos 6.4 и Postgres 9.2.
  • Потоковая репликация настраивается от мастера к подчиненному с помощью встроенной репликации Postgres.
  • Отработка отказа обрабатывается драйвером Postgresql JDBC (v9.2-1003) путем указания ведущего / ведомого устройства в строке подключения.

Я хочу продолжать использовать этот метод репликации.

Вопросы:

  • Подчиненный сервер доступен только для чтения. Как я могу сделать это мастером (доступным для записи) после автоматического переключения?
  • Что, если первоначальный мастер внезапно снова начнет работать, и теперь у нас будет два мастера? Как я могу выстрелить оригинальному мастеру в голову? Автоматически.

postgresql streaming replication failover pgpool
person Zaute    schedule 18.10.2013    source источник
comment
Что вы делаете после отказа главного сервера и переключения системы на подчиненный сервер? Как восстановить хозяина и сделать его снова мастером, или он просто становится рабом?   -  person Michał Maciej Gałuszka    schedule 03.09.2014

Ответы (3)


arrow_upward
3
arrow_downward

Предлагаю взглянуть на pgpool с опцией failover_command. Там у вас может быть небольшой сценарий оболочки для перезапуска ведомого устройства в режиме чтения / записи. pgpool

Если у вас возникнут проблемы с pgpool, может помочь этот процесс, который я выполнил для устранения неполадок - pgpool - stracing

person Jayadevan    schedule 06.11.2013

arrow_upward
1
arrow_downward

PGPool-II сделал свое дело.

Я установил PGPool на третий сервер; сервер мониторинга, также работающий под управлением CentOS. Я настроил проверку работоспособности каждые 10 секунд. Команда failover_command была настроена для запуска небольшого сценария оболочки, который генерирует файл триггера на подчиненном сервере в случае отказа главного сервера. И это сработало отлично.

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

Спасибо за совет!

person Zaute    schedule 12.11.2013

arrow_upward
0
arrow_downward

Если вы хотите использовать решение на основе Docker, попробуйте PostDock.

В настоящее время я пробовал это в нашем проекте с docker-compose со схемой, показанной ниже:

pgmaster (primary node1)  --|
|- pgslave1 (node2)       --|
|  |- pgslave2 (node3)    --|----pgpool (master_slave_mode stream)----client
|- pgslave3 (node4)       --|
   |- pgslave4 (node5)    --|

Я протестировал следующие сценарии, и все они работают очень хорошо:

  • Репликация: изменения, внесенные на первичном (т. Е. Главном) узле, будут реплицированы на все резервные (т. Е. Подчиненные) узлы.
  • Отработка отказа: останавливает основной узел, а резервный узел (например, node4) автоматически принимает на себя основную роль.
  • Предотвращение появления двух основных узлов: воскресите предыдущий основной узел (node1), node4 продолжит работу как основной узел, а node1 будет синхронизироваться, но как резервный узел.

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

Примечание. Если у вас возникли проблемы с запуском PostDock, вы можете попробовать мою разветвленную версию PostDock.

Pgpool-II со сторожевым псом

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

master (primary node1)  --\
|- slave1 (node2)       ---\     / pgpool1 (active)  \
|  |- slave2 (node3)    ----|---|                     |----client
|- slave3 (node4)       ---/     \ pgpool2 (standby) /
   |- slave4 (node5)    --/

Я протестировал следующие сценарии, и все они работают очень хорошо:

  • Нормальный сценарий: оба pgpools запускаются, и виртуальный IP-адрес автоматически применяется к одному из них, в моем случае pgpool1
  • Аварийное переключение: завершение работы pgpool1. Виртуальный IP-адрес будет автоматически применен к pgpool2, который, следовательно, станет активным.
  • Не удалось запустить pgpool: запустить снова pgpool1. Виртуальный IP-адрес будет храниться в pgpool2, а pgpool1 теперь работает как резервный.

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

Вы можете найти этот проект в моем репозитории GitHub в ветке сторожевого пса.

person Yuci    schedule 14.12.2017