Я оцениваю PostgreSQL 9.1 и у меня есть несколько вопросов, связанных с отказоустойчивостью и деталями репликации.
У меня есть несколько тестовых сценариев. Первый с главным сервером и несколькими рабами. В случае сбоя Мастера я хочу, чтобы Один из Рабов стал Мастером. После того, как Master вернется в нормальное состояние, он должен синхронизироваться с другими серверами в кластере (применить все изменения, сделанные, когда он был выключен) и вернуть себе роль Master или стать Slave.
Проблемы, которые я вижу с PostgreSQL и текущим сценарием, следующие.
1) Я не вижу встроенных инструментов для обнаружения простоя главного сервера. Я читал, что pgpool может с этим справиться и создает файл триггера, я также читал, что люди используют Linux heartbeat или аналогичные инструменты для этого. Хорошо, я могу обнаружить аварийное переключение и назначить нового Мастера в кластере. Понимают ли другие Рабы, что есть новый Мастер, и они должны поддержать его сейчас?
2) Я не понимаю процедуру восстановления после отказа. Конфигурации главного и подчиненного хоста разные. Так будет ли у меня два Мастера после сбоя Мастера? Как серверы вернутся в синхронизацию? Я видел только ручные решения, такие как «перенести папку данных на сервер и перезапустить ее». Так в чем же заключается решение, лучшая практика или, по крайней мере, ключевой принцип?
3) Как мне справиться с перебоями в работе сервера на стороне клиента? Когда я создаю соединение, я явно указываю IP-адрес сервера. Должен ли я разработать какой-либо тип ConnectionManager, который будет знать мою структуру Master-Slave, отправлять запросы только Master, а в случае потери соединения переключится на резервные серверы и т. Д.? Я читал, что pgpool может быть точкой входа для приложений и правильно управлять соединениями. Является ли pgpool единственным решением здесь? Хорошо ли он справляется с восстановлением после отказа
4) Существуют ли какие-либо решения (в том числе и коммерческие), чтобы я мог избежать копирования данных вручную, перенастройки экземпляров PostgreSQL и прочего, что нужно делать руками? Так что вроде конфигурации кластера, когда все синхронизированы, понятно, кто такой Мастер, и все переключается автоматически, без внимания оператора?
По этим темам и статьям
Потоковая репликация и отработка отказа в PostgreSQL
Автоматизация отработки отказа в PostgreSQL 9.1
http://denishjpatel.blogspot.com/2010/11/possibility-of-graceful-switchover.html
не существует единого полностью автоматического решения для решения этих вопросов. Я прав?
Благодарность!