¿Cómo puedo modelar un clúster de conmutación por error de PostgreSQL con Docker/Kubernetes?
(3)
Todavía estoy envolviendo mi cabeza con Kubernetes y cómo se supone que funciona. Actualmente, me cuesta entender cómo modelar algo como un clúster de PostgreSQL con replicación de transmisión, ampliación y recuperación automática en caso de fallos / pgpool-II ( pgpool-II , repmgr , pick your poison).
Mi principal problema con el enfoque es la naturaleza dual de una instancia de PostgreSQL, en lo que respecta a la configuración: es un maestro o un modo de espera frío / calor / calor. Si aumente el número de réplicas, esperaría que todas se convirtieran en standby, por lo que me imagino creando un controlador de replicación postgresql-standby por separado desde un pod postgresql-master . Sin embargo, también esperaría que uno de esos recursos se convierta en maestro en caso de que el maestro actual esté fuera de servicio, por lo que, después de todo, es un controlador de replicación postgresql común.
La única idea que he tenido hasta ahora es poner la configuración de replicación en un volumen externo y administrar el estado y los cambios de estado fuera de los contenedores.
(En el caso de PostgreSQL, la configuración probablemente ya estaría en un volumen dentro de su directorio de data , lo que obviamente es algo que desearía en un volumen, pero eso no viene al caso)
¿Es ese el enfoque correcto, o hay alguna otra forma más limpia?
El estado de Kubernetes es una buena base para configurar el servicio con estado. Aún necesitará algo de trabajo para configurar la membresía correcta entre las réplicas de PostgreSQL.
Kubernetes tiene un ejemplo para ello. http://blog.kubernetes.io/2017/02/postgresql-clusters-kubernetes-statefulsets.html
Hay un ejemplo en OpenShift: https://github.com/openshift/postgresql/tree/master/examples/replica El principio es el mismo en Kube puro (no usa nada realmente específico de OpenShift, y puede usar las imágenes en plano estibador)
Puedes darle una oportunidad a PostDock , ya sea con docker-compose o Kubernetes. Actualmente lo he intentado en nuestro proyecto con docker-compose, con el esquema como se muestra a continuación:
pgmaster (primary node1) --|
|- pgslave1 (node2) --|
| |- pgslave2 (node3) --|----pgpool (master_slave_mode stream)----client
|- pgslave3 (node4) --|
|- pgslave4 (node5) --|
He probado los siguientes escenarios, y todos funcionan muy bien:
- Replicación: los cambios realizados en el nodo primario (es decir, maestro) se replicarán en todos los nodos en espera (es decir, esclavos)
- Conmutación por error: detiene el nodo primario y un nodo en espera (p. Ej., Node4) asumirá automáticamente la función principal.
- Prevención de dos nodos primarios: resucitar el nodo primario anterior (nodo1), nodo4 continuará como nodo primario, mientras que nodo1 estará sincronizado pero como nodo de reserva.
En cuanto a la aplicación cliente, todos estos cambios son transparentes. El cliente solo apunta al nodo pgpool y sigue funcionando bien en todos los escenarios mencionados.
Nota : En caso de que tenga problemas para poner en marcha PostDock, puede probar mi versión bifurcada de PostDock .
Pgpool-II con Watchdog
Un problema con la arquitectura mencionada es que pgpool es el único punto de falla. Así que también he intentado habilitar Watchdog para pgpool-II con una IP virtual delegada, para evitar el único punto de falla.
master (primary node1) --/
|- slave1 (node2) ---/ / pgpool1 (active) /
| |- slave2 (node3) ----|---| |----client
|- slave3 (node4) ---/ / pgpool2 (standby) /
|- slave4 (node5) --/
He probado los siguientes escenarios, y todos funcionan muy bien:
- Escenario normal: ambos pgpools se inician, con la IP virtual aplicada automáticamente a uno de ellos, en mi caso, pgpool1
- Failover: shutdown pgpool1. La IP virtual se aplicará automáticamente a pgpool2, que por lo tanto se activa.
- Inicio fallido pgpool: vuelva a iniciar pgpool1. La IP virtual se mantendrá con pgpool2, y pgpool1 ahora está funcionando en modo de espera.
En cuanto a la aplicación cliente, todos estos cambios son transparentes. El cliente solo apunta a la IP virtual y sigue funcionando bien en todos los escenarios mencionados.
Puede encontrar este proyecto en mi repositorio de GitHub en la rama de vigilancia .