Как создать отказоустойчивый кластер PostgreSQL с помощью Docker/Kubernetes?

Question

Я все еще обнимаю Кубернеса и как это должно работать. В настоящее время я изо всех сил пытаюсь понять, как моделировать что-то вроде кластера PostgreSQL с потоковой репликацией, масштабированием и автоматическим откатом/откатом (pgpool-II, repmgr, забрать свой яд).

Моей главной проблемой при подходе является двойственная природа экземпляра PostgreSQL, конфигурация - это либо главный, либо холодный/теплый/горячий режим ожидания. Если я увеличу количество реплик, я бы ожидал, что они все придумают как standbys, поэтому я бы предположил, что создавал контроллер репликации отдельно от подкаталога postgresql-master. Однако я также ожидал, что один из этих standbys станет мастером в случае, если текущий мастер не работает, поэтому он является общим контроллером репликации postgresql.

Единственная идея, которую я имел до сих пор, - это установить конфигурацию репликации на внешний том и управлять изменениями состояния и состояния за пределами контейнеров.

(в случае PostgreSQL конфигурации, вероятно, уже быть на томе внутри его data директории, которая сама по себе, очевидно, что-то я хочу на томе, но это рядом с точкой)

Это правильный подход, или есть ли другой более чистый способ?

Answer 1

Там пример в OpenShift: https://github.com/openshift/postgresql/tree/master/examples/replica Принцип тот же в чистой Кубэ (это не использовать что-либо по-настоящее OpenShift конкретное, и вы можете использовать изображения в простом докер) statefulset

Answer 2

Kubernetes является хорошей базой для установки достоянием государственной службы. Вам по-прежнему потребуется некоторая работа по настройке правильного членства в репликах PostgreSQL.

У Кубернете есть один пример. http://blog.kubernetes.io/2017/02/postgresql-clusters-kubernetes-statefulsets.html

Answer 3

Вы можете дать PostDock попытку, с помощью docker-compose или Kubernetes. В настоящее время я попробовал это в нашем проекте с Докером-композом, со схемой, как показано ниже:

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

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

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

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

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

PGPool-II с Watchdog

Проблема с вышеупомянутой архитектуры является то, что PGPool является единственной точкой отказа. Поэтому я также попытался включить Watchdog for 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-адрес и отлично работает во всех вышеупомянутых сценариях.

Вы можете найти этот проект на my GitHub repository on the watchdog branch.