Я оцениваю 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
не существует единого полностью автоматического решения для решения этих вопросов. Я прав?
Благодарность!
источник
Ответы:
да, они разные, и вы должны создать новые для старого master.however старый резерв будет продолжать работать как master, но вы должны установить max_wal_senders на этом узле. Вы также должны установить pg_hba.conf нового мастера после аварийного переключения. после отработки отказа (когда узлы изменяют роли master-> slave-slave-> master), вы должны перенести новые файлы wal в новый каталог данных резервных папок, который вы указали в файле recovery.conf. или просто вы можете использовать rsync.
может быть, вы можете использовать pgbouncer. Таким образом, вы просто измените адрес сервера pgbouncer на новый master.
EnterpriseDB имеет несколько коммерческих инструментов. может быть, вы можете проверить их.
и, наконец, да, вы правы. не существует единого полностью автоматического решения для решения этих вопросов.
источник