Репликация Postgresql с помощью pgpool или pgbouncer
Я ищу хорошую конфигурацию для репликации postgresql с надежной стратегией аварийного переключения (самостоятельное размещение).
Фактически, я настроил два экземпляра postgresql в главном / подчиненном режиме с помощью repmgr. Теперь я не знаю, что поставить перед этими двумя экземплярами, чтобы обеспечить хорошее переключение при отказе.
Я бы хотел, чтобы, когда ведущее устройство выходит из строя, ведомое устройство автоматически продвигается к новому мастеру и без простоев для клиентов; Я думаю, что я должен поставить pgbool (или pgbouncer?) Перед postgres master / slave, но чтобы избежать его как единой точки отказа, у меня должно быть 2 экземпляра этого, верно? (это пример того, что я имел в виду: http://i.imgur.com/yqky2bl.png ).
Моя основная проблема заключается в том, как настроить автоматическое аварийное переключение с двумя разными экземпляры pgpool. Как я могу быть уверен, что оба меняют внутреннюю конфигурацию ведущий / ведомый? Должен ли быть pgpool для отработки отказа или repmgr (изменение конфигурации обоих экземпляров pgpool)?
У меня есть некоторые сомнения, что я на правильном пути, в основном потому, что я не нашел много документации об этом типе конфигурации, и что может случиться, если, например, мастер снова подключится к сети, возможно, через несколько минут после проблем с сетью (так что postgres на самом деле не работает, но недоступен для клиентов).
Чтобы усложнить задачу, я пытаюсь настроить эта инфраструктура с докером (но, может быть, это может быть проще, потому что я могу уничтожить экземпляр pg и создать новый с помощью docker?).
Я никогда не использовал docker, поэтому не могу это прокомментировать, но я бы порекомендовал (и я использую это в производстве для больших, сильно используемых баз данных в течение долгого времени), на мой взгляд, способ входа в (сложную) кластерную установку: коросинхронизация и кардиостимулятор . Используйте pgsql агент ресурсов и виртуальный, плавающий IP, к которому вы подключаете клиентов.
Если вы никогда не работали с таким типом установки / программного стека, посмотрите на это учебное пособие или , что это ; кроме того здесь являются слайдами (будьте осторожны, это .pdf, в случае, если это имеет значение для вас) об этой теме из PGConf.Russia, проведенной в прошлом году. Если вы пойдёте по этому маршруту и столкнётесь с конкретными проблемами, откроете новый вопрос и пингуете мне (например, через комментарий с помощью @gf_), я смогу помочь.
Правка: Также появился новый проект под названием PostgreSQL Automatic Failover PAF, который "[...] является новым OCF-ресурсом, посвящённым PostgreSQL". Его первоначальное желание - сохранить четкий предел между администрированием Pacemaker и PostgreSQL, чтобы всё было просто, документировано и в то же время мощно. [...]" Первое обязательство было сделано в феврале 2016 года, так что это еще довольно молодой, но, возможно, это стоило бы посмотреть также. (Тем не менее, я не могу ни комментировать, ни судить об этом, потому что я никогда не использовал его.)
.