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