sql >> Base de Datos >  >> RDS >> PostgreSQL

Gestión de alta disponibilidad en PostgreSQL – Parte III:Patroni

En nuestras publicaciones de blog anteriores, discutimos las capacidades y el funcionamiento de PostgreSQL Automatic Failover (PAF) de Cluster Labs y Replication Manager (repmgr) de 2ndQuadrant. En la publicación final de esta serie, revisaremos la última solución, Patroni de Zalando, y compararemos las tres al final para que pueda determinar qué marco de trabajo de alta disponibilidad es mejor para su implementación de alojamiento de PostgreSQL.

  • Gestión de alta disponibilidad en PostgreSQL - Parte I:Conmutación por error automática de PostgreSQL
  • Gestión de alta disponibilidad en PostgreSQL - Parte II:Administrador de replicación

Patroni para PostgreSQL

Patroni se originó como una bifurcación de Governor, un proyecto de Compose. Es un conjunto de herramientas de código abierto, escrito en Python, para administrar la alta disponibilidad de los clústeres de PostgreSQL. En lugar de crear su propio protocolo de coherencia, Patroni aprovecha de forma inteligente el modelo de coherencia proporcionado por un Almacén de configuración distribuida (DCS). También es compatible con otras soluciones DCS como Zookeeper, etcd, Consul y Kubernetes.

Patroni garantiza la configuración integral de los clústeres de alta disponibilidad de PostgreSQL, incluida la replicación de transmisión. Admite varias formas de crear un nodo en espera y funciona como una plantilla que se puede personalizar según sus necesidades.

Esta herramienta rica en características expone su funcionalidad a través de API REST y también a través de una utilidad de línea de comandos llamada patronictl. Admite la integración con HAProxy mediante el uso de sus API de verificación de estado para manejar el equilibrio de carga.

Patroni también admite la notificación de eventos con la ayuda de devoluciones de llamada, que son secuencias de comandos activadas por ciertas acciones. Permite a los usuarios realizar cualquier acción de mantenimiento proporcionando funcionalidad de pausa/reanudar. La función de compatibilidad con Watchdog hace que el marco sea aún más sólido.

Cómo funciona

Inicialmente, se deben instalar los binarios de PostgreSQL y Patroni. Una vez hecho esto, también deberá establecer una configuración HA DCS. Todas las configuraciones necesarias para arrancar el clúster deben especificarse en el archivo de configuración yaml y Patroni usará este archivo para la inicialización. En el primer nodo, Patroni inicializa la base de datos, obtiene el bloqueo líder de DCS y se asegura de que el nodo se ejecute como maestro.

El siguiente paso es agregar nodos en espera, para los cuales Patroni brinda múltiples opciones. De forma predeterminada, Patroni usa pg_basebackup para crear el nodo en espera y también admite métodos personalizados como WAL-E, pgBackRest, Barman y otros para la creación del nodo en espera. Patroni hace que sea muy sencillo agregar un nodo en espera y maneja todas las tareas de arranque y la configuración de su replicación de transmisión.

Gestión de alta disponibilidad en #PostgreSQL – Parte III:Patroni vs. PAF vs. repmgrHaga clic para twittear

Una vez que se haya completado la configuración de su clúster, Patroni supervisará activamente el clúster y se asegurará de que esté en buen estado. El nodo maestro renueva el bloqueo líder cada ttl segundo(s) (predeterminado:30 segundos). Cuando el nodo maestro no puede renovar el bloqueo de líder, Patroni activa una elección y el nodo que obtendrá el bloqueo de líder será elegido como nuevo maestro.

¿Cómo maneja el escenario del cerebro dividido?

En un sistema distribuido, el consenso juega un papel importante en la determinación de la consistencia, y Patroni usa DCS para lograr el consenso. Solo el nodo que tiene el bloqueo de líder puede ser el maestro y el bloqueo de líder se obtiene a través de DCS. Si el nodo maestro no mantiene el bloqueo de líder, Patroni lo degradará inmediatamente para que se ejecute como en espera. De esta manera, en cualquier momento, solo puede haber un maestro ejecutándose en el sistema.

¿Hay algún requisito de configuración?

  • Patroni necesita Python 2.7 y superior.
  • El DCS y su módulo Python específico deben estar instalados. Para fines de prueba, DCS se puede instalar en los mismos nodos que ejecutan PostgreSQL. Sin embargo, en producción, DCS debe instalarse en nodos separados.
  • El archivo de configuración de yaml debe estar presente con estos ajustes de configuración de alto nivel:

    Global/Universal
    Esto incluye configuraciones como el nombre del host (nombre) que debe ser único para el clúster, el nombre del clúster (ámbito) y la ruta para almacenar la configuración en DCS (espacio de nombres).

    Iniciar sesión
    Configuraciones de registro específicas de Patroni, incluidos nivel, formato, número_de_archivo, tamaño_de_archivo, etc.

    Configuración de Bootstrap
    Esta es la configuración global para un clúster que se escribirá en DCS. Estos parámetros de configuración se pueden cambiar con la ayuda de las API de Patroni o directamente en DCS. La configuración de arranque incluye métodos de creación en espera, parámetros de initdb, script de inicialización posterior, etc. También contiene configuración de tiempos de espera, parámetros para decidir el uso de funciones de PostgreSQL como ranuras de replicación , modo síncrono, etc. Esta sección se escribirá en ///config de un almacén de configuración determinado después de la inicialización del nuevo clúster.

    PostgreSQL
    Esta sección contiene los parámetros específicos de PostgreSQL como autenticación, rutas de directorio para datos, binario y configuración, dirección IP de escucha, etc.

    API REST
    Esta sección incluye la configuración específica de Patroni relacionada con las API REST, como la dirección de escucha, la autenticación, SSL, etc.

    Cónsul
    Configuraciones específicas de Consul DCS.

    Etcd
    Configuración específica de Etcd DCS.

    Expositor
    Configuración específica para Expositor DCS.

    Kubernetes
    Configuración específica de Kubernetes DCS.

    ZooKeeper
    Configuración específica de ZooKeeper DCS.

    Perro guardián
    Configuración específica de Watchdog.

Patroni Pros

  • Patroni permite la configuración integral del clúster.
  • Admite API REST e integración HAproxy.
  • Admite notificaciones de eventos a través de scripts de devolución de llamada activados por ciertas acciones.
  • Aprovecha DCS para el consenso.

Contras de Patroni

  • Patroni no detectará la configuración incorrecta de un modo de espera con un nodo desconocido o inexistente en la configuración de recuperación. El nodo se mostrará como esclavo incluso si el modo en espera se está ejecutando sin conectarse al nodo maestro/en espera en cascada.
  • El usuario debe encargarse de la configuración, administración y actualización del software DCS.
  • Requiere que varios puertos estén abiertos para la comunicación de los componentes:
    • Puerto API REST para Patroni
    • Mínimo 2 puertos para DCS

Escenarios de prueba de alta disponibilidad

Realizamos algunas pruebas sobre la gestión de alta disponibilidad de PostgreSQL con Patroni. Todas estas pruebas se realizaron mientras la aplicación se ejecutaba e insertaba datos en la base de datos de PostgreSQL. La aplicación se escribió utilizando el controlador PostgreSQL Java JDBC aprovechando la capacidad de conmutación por error de la conexión.

Pruebas de servidor en espera

Sl. No Escenario de prueba Observación
1 Elimine el proceso de PostgreSQL Patroni devolvió el proceso de PostgreSQL al estado de ejecución.

  • No hubo interrupción de la aplicación de escritura.
2 Detenga el proceso de PostgreSQL Patroni devolvió el proceso de PostgreSQL al estado de ejecución.

  • No hubo interrupción de la aplicación de escritura.
3 Reiniciar el servidor Patroni debe iniciarse después de reiniciar, a menos que esté configurado para no iniciarse al reiniciar. Una vez que se inició Patroni, inició el proceso de PostgreSQL y estableció la configuración en espera.

  • No hubo interrupción de la aplicación de escritura.
4 Detener el proceso Patroni
  • No detuvo el proceso de PostgreSQL.
  • lista de patrocinadores no mostró este servidor.
  • No hubo interrupción de la aplicación de escritura.

Entonces, esencialmente, debe monitorear la salud del proceso Patroni; de lo contrario, generará problemas en el futuro.

Pruebas de servidor maestro/principal

Sl. No Escenario de prueba Observación
1 Elimine el proceso de PostgreSQL Patroni devolvió el proceso de PostgreSQL al estado de ejecución. Patroni ejecutándose en ese nodo tenía un bloqueo primario, por lo que no se activó la elección.

  • Hubo un tiempo de inactividad en la aplicación de escritura.
2 Detenga el proceso de PostgreSQL y tráigalo inmediatamente después de que caduque la verificación de estado Patroni devolvió el proceso de PostgreSQL al estado de ejecución. Patroni ejecutándose en ese nodo tenía un bloqueo primario, por lo que no se activó la elección.

  • Hubo un tiempo de inactividad en la aplicación de escritura.
3 Reiniciar el servidor Ocurrió una conmutación por error y uno de los servidores en espera fue elegido como el nuevo maestro después de obtener el bloqueo. Cuando Patroni se inició en el maestro anterior, volvió a subir el maestro anterior y realizó pg_rewind y comenzó a seguir el nuevo maestro. T

  • Hubo un tiempo de inactividad en la aplicación de escritura.
4 Detener/Eliminar el proceso Patroni
  • Uno de los servidores en espera adquirió el bloqueo de DCS y se convirtió en maestro al promocionarse a sí mismo.
  • El antiguo maestro todavía se estaba ejecutando y condujo a un escenario multimaestro. La aplicación seguía escribiendo en el antiguo maestro.
  • Una vez que Patroni se inició en el maestro anterior, rebobinó el maestro anterior (use_pg_rewind se configuró en verdadero) a la nueva línea de tiempo maestra y lsn y comenzó a seguir al nuevo maestro.

Como puede ver arriba, es muy importante monitorear la salud del proceso Patroni en el maestro. Si no lo hace, puede generar un escenario multimaestro y una posible pérdida de datos.

Pruebas de aislamiento de red

Sl. No Escenario de prueba Observación
1 Red:aísle el servidor maestro de otros servidores Se bloqueó la comunicación DCS para el nodo maestro.

  • PostgreSQL fue degradado en el servidor maestro.
  • Se eligió un nuevo maestro en la partición mayoritaria.
  • Hubo un tiempo de inactividad en la aplicación de escritura.
2 Red:aísle el servidor en espera de otros servidores Se bloqueó la comunicación DCS para el nodo en espera.

  • El servicio PostgreSQL se estaba ejecutando, sin embargo, el nodo no se consideró para las elecciones.
  • No hubo interrupciones en la aplicación de escritura.

¿Cuál es el mejor framework PostgreSQL HA?

Patroni es una herramienta valiosa para los administradores de bases de datos (DBA) de PostgreSQL, ya que realiza la configuración y el control de un clúster de PostgreSQL de un extremo a otro. La flexibilidad de elegir DCS y la creación en espera es una ventaja para el usuario final, ya que puede elegir el método con el que se sienta cómodo.

Las API REST, la integración de HaProxy, la compatibilidad con Watchdog, las devoluciones de llamadas y su gestión rica en funciones hacen de Patroni la mejor solución para la gestión de alta disponibilidad de PostgreSQL.

Pruebas del marco PostgreSQL HA:PAF frente a repmgr frente a Patroni

A continuación se incluye una tabla completa que detalla los resultados de todas las pruebas que hemos realizado en los tres marcos:PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) y Patroni.

Pruebas de servidor en espera

Escenario de prueba Conmutación automática por error de PostgreSQL (PAF) Administrador de replicación (repmgr) Patroni
Elimine el proceso de PostgreSQL Pacemaker devolvió el proceso de PostgreSQL al estado de ejecución.

  • No hubo interrupción de la aplicación de escritura.
 El servidor en espera se marcó como fallido. Se requirió una intervención manual para iniciar el proceso de PostgreSQL nuevamente.

  • No hubo interrupción de la aplicación de escritura.
 Patroni devolvió el proceso de PostgreSQL al estado de ejecución.

  • No hubo interrupción de la aplicación de escritura.
Detener el proceso de PostgreSQL Pacemaker devolvió el proceso de PostgreSQL al estado de ejecución.

  • No hubo interrupción de la aplicación de escritura.
 El servidor en espera se marcó como fallido. Se requirió una intervención manual para iniciar el proceso de PostgreSQL nuevamente.

  • No hubo interrupción de la aplicación de escritura.
 Patroni devolvió el proceso de PostgreSQL al estado de ejecución.

  • No hubo interrupción de la aplicación de escritura.
Reiniciar el servidor El servidor en espera se marcó inicialmente como fuera de línea. Una vez que el servidor apareció después de reiniciar, Pacemaker inició PostgreSQL y el servidor se marcó como en línea. Si el cercado estuviera habilitado, el nodo no se habría agregado automáticamente al clúster.

  • No hubo interrupción de la aplicación de escritura.
 El servidor en espera se marcó como fallido. Una vez que el servidor apareció después de reiniciar, PostgreSQL se inició manualmente y el servidor se marcó como en ejecución.

  • No hubo interrupción de la aplicación de escritura.
 Patroni debe iniciarse después de reiniciar, a menos que esté configurado para no iniciarse al reiniciar. Una vez que se inició Patroni, inició el proceso de PostgreSQL y estableció la configuración en espera.

  • No hubo interrupción de la aplicación de escritura.
Detener el proceso del agente del marco Agente:marcapasos

  • El proceso de PostgreSQL se detuvo y se marcó como fuera de línea.
  • No hubo interrupción de la aplicación de escritura.
 Agente:repmgrd

  • El servidor en espera no formará parte de una situación de conmutación por error automatizada.
  • Se encontró que el servicio PostgreSQL se estaba ejecutando.
  • No hubo interrupción de la aplicación de escritura.
 Agente:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

Master/Primary Server Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back.Cluster was left in an indeterminate state and manual intervention was required.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. The most eligible standby server was promoted as the new master. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Network Isolation Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • The eligible standby was promoted, but the PostgreSQL process was still running on the old master node.
  • There were two nodes running as master. Manual intervention was required after the network isolation was corrected.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had location different from that of the primary.
  • repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.