Gestión de la alta disponibilidad de PostgreSQL - Parte I:Conmutación automática por error de PostgreSQL

La gestión de alta disponibilidad (HA) en su hosting de PostgreSQL es un tema muy importante para garantizar que los clústeres de implementación de su base de datos mantengan un tiempo de actividad excepcional y un sólido rendimiento operativo para que sus datos estén siempre disponibles para su aplicación. En una publicación de blog anterior, le presentamos cómo configurar la alta disponibilidad para PostgreSQL mediante la replicación de transmisión y ahora le mostraremos cómo administrar mejor la alta disponibilidad del lado del cliente.

Hay varias herramientas disponibles para administrar la alta disponibilidad (HA) de sus clústeres de implementación de PostgreSQL mediante la replicación de transmisión. Estas soluciones ofrecen capacidades automáticas de conmutación por error, monitorean la disponibilidad y el estado del sistema, replicación, administración de usuarios y otras tareas administrativas útiles en casos de uso para bases de datos de Postgres. Algunas de las soluciones de código abierto destacadas incluyen:

Conmutación por error automática de PostgreSQL de ClusterLabs
Administrador de replicación para clústeres de PostgreSQL por repmgr (2ndQuadrant)
Patroni de Zalando

Cada herramienta proporciona su propia forma de administrar los clústeres de PostgreSQL de alta disponibilidad. En nuestra serie de publicaciones de tres partes sobre HA para PostgreSQL, compartiremos una descripción general, los requisitos previos y los resultados de trabajo y prueba para cada una de estas tres herramientas. Aquí, en la Parte 1, profundizaremos en la solución PAF de ClusterLabs.

Gestión de alta disponibilidad en PostgreSQL - Parte II:Administrador de replicación
Gestión de alta disponibilidad en PostgreSQL - Parte III:Patroni

¿Cómo administrar la alta disponibilidad de su base de datos PostgreSQL?

PostgreSQL Automatic Failover (PAF) es una solución de gestión de alta disponibilidad para PostgreSQL de ClusterLabs. Utiliza la replicación síncrona de Postgres para garantizar que no se pierdan datos en el momento de la operación de conmutación por error. Hace uso de la popular pila Pacemaker y Corosync estándar de la industria. Con las aplicaciones Pacemaker y Corosync juntas, podrá detectar fallas de la base de datos PostgreSQL en el sistema y actuar en consecuencia.

Pacemaker es un servicio capaz de administrar muchos recursos y lo hace con la ayuda de sus agentes de recursos. Los agentes de recursos luego tienen la responsabilidad de manejar un recurso específico, cómo deben comportarse e informar a Pacemaker de sus resultados.

La implementación de su agente de recursos debe cumplir con la especificación Open Cluster Framework (OCF). Esta especificación define el comportamiento de los agentes de recursos y la implementación de métodos como detener, iniciar, promover, degradar e interactuar con Pacemaker.

PAF es un agente de recursos OCF para Postgres escrito en Perl. Una vez que su clúster de base de datos se crea utilizando la replicación de transmisión interna, PAF puede exponer a Pacemaker el estado actual de la instancia de PostgreSQL en cada uno de los nodos de la base de datos:maestro, esclavo, detenido, poniéndose al día, equilibrador de carga, etc.

Cómo funciona la conmutación por error automática de Postgres

PAF se comunica con Pacemaker con respecto al estado del clúster y supervisa el funcionamiento de la base de datos PostgreSQL. En caso de falla, informa a Pacemaker y, si no hay posibilidad de que se recupere el maestro actual, activará una elección entre uno de los servidores de base de datos en espera actuales. Con el robusto Pacemaker instalado, la conmutación por error automática de Postgres realizará acciones de administración como iniciar, detener, monitorear y conmutar por error en todos los nodos de las bases de datos de Postgres.

Gestión de alta disponibilidad en PostgreSQL - Parte I:Conmutación por error automática de ClusterLabsHaga clic para twittear

Conmutación por error automática de PostgreSQL para configuración de alta disponibilidad (HA)

PAF es compatible con PostgreSQL versión 9.3 y superior.
PAF no es responsable de la creación de instancias maestras/en espera de PostgreSQL ni de su configuración; debe crear y configurar la replicación de transmisión antes de usar PAF.
PAF no edita ningún requisito de configuración o instalación de PostgreSQL. Sin embargo, requiere que los usuarios de la base de datos sigan algunos requisitos previos como:
- El esclavo debe configurarse como modo de espera activo. Los nodos esclavos en espera activa se pueden consultar como bases de datos de solo lectura.
- Se debe proporcionar un archivo de plantilla de recuperación (predeterminado:
  /recovery.conf.pcmk) con los siguientes parámetros:
  - modo_espera =encendido
  - recovery_target_timeline ='más reciente'
  - primary_conninfo debe tener el parámetro application_name definido y establecido en el nombre del nodo local como en Pacemaker.
PAF expone múltiples parámetros relacionados con la administración de un recurso de Postgres. Esto se puede configurar para adaptarse a los requisitos de cada uno. A continuación se muestran los parámetros:
- bindir: ubicación de los binarios de PostgreSQL (predeterminado:/usr/bin)
- datos pg: ubicación del PGDATA de su instancia (predeterminado:/var/lib/pgsql/data)
- dirección de datos: ruta al directorio establecido en data_directory desde su archivo postgresql.conf
- pfantasma: el directorio del socket o la dirección IP que se usará para conectarse a la instancia local (predeterminado:/tmp)
- puerto pg: el puerto para conectarse a la instancia local (predeterminado:5432)
- recovery_template: la plantilla local que se copiará como el archivo PGDATA/recovery.conf. Este archivo de plantilla debe existir en todos los nodos (predeterminado:$PGDATA/recovery.conf.pcmk)
- opciones de inicio: Argumentos adicionales dados al proceso de Postgres en el inicio. Consulte “postgres –help” para conocer las opciones disponibles. Útil cuando el archivo postgresql.conf no está en el directorio de datos (PGDATA), por ejemplo:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
- usuario_del_sistema: el propietario del sistema del proceso de su instancia (predeterminado:postgres)
- retraso máximo: retraso máximo permitido en modo de espera antes de que establezcamos una puntuación maestra negativa

Profesiones de conmutación por error automática de Postgres

PAF proporciona al usuario una configuración práctica y gratuita de PostgreSQL.
PAF puede manejar la falla del nodo y desencadenar elecciones cuando el maestro deja de funcionar.
El comportamiento del quórum se puede imponer en PAF.
Proporcionará una solución completa de administración de bases de datos de alta disponibilidad (HA) para el recurso, que incluye iniciar, detener y monitorear, y manejar escenarios de aislamiento de red.
Es una solución distribuida, que permite la gestión de cualquier nodo desde otro nodo.

Desventajas de la conmutación por error automática de Postgres

PAF no detecta si un nodo en espera está mal configurado con un nodo desconocido o inexistente en la configuración de recuperación. El nodo se mostrará como esclavo, incluso si el modo de espera se está ejecutando sin conectarse al nodo maestro/en espera en cascada.
Requiere que se abra un puerto adicional (predeterminado 5405) para la comunicación de los componentes Pacemaker y Corosync mediante UDP.
No es compatible con la configuración basada en NAT.
No hay soporte para pg_rewind.

Alta disponibilidad para escenarios de prueba de PostgreSQL

Realizamos algunas pruebas para determinar la capacidad de la gestión de alta disponibilidad (ha) de PostgreSQL mediante PAF en algunos casos de uso. Todas estas pruebas se ejecutaron mientras la aplicación se ejecutaba e insertaba datos en la base de datos PostgreSQL. La aplicación se escribió con PostgreSQL Java JDBC Driver 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	Pacemaker devolvió el proceso de PostgreSQL al estado de ejecución. No hubo interrupciones en la aplicación del escritor.
2	Detenga el proceso de PostgreSQL	Pacemaker devolvió el proceso de PostgreSQL al estado de ejecución. No hubo interrupciones en la aplicación del escritor.
3	Reiniciar el servidor	El nodo del servidor de la base de datos en espera se marcó inicialmente como fuera de línea. Una vez que el servidor apareció después de reiniciar, Pacemaker inició la base de datos 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 interrupciones en la aplicación del escritor.
4	Detener el proceso de marcapasos	También detendrá el proceso de PostgreSQL y el nodo del servidor se marcará como fuera de línea. No hubo interrupciones en la aplicación del escritor.

Pruebas de servidor maestro/principal

Sl. No	Escenario de prueba	Observación
1	Elimine el proceso de PostgreSQL	Pacemaker devolvió el proceso de PostgreSQL al estado de ejecución. La primaria se recuperó dentro del tiempo umbral y, por lo tanto, no se activó la elección. La aplicación de escritura estuvo inactiva durante unos 26 segundos.
2	Detener el proceso de PostgreSQL	Pacemaker devolvió el proceso de PostgreSQL al estado de ejecución. La primaria se recuperó dentro del tiempo umbral y, por lo tanto, no se activó la elección. Hubo un tiempo de inactividad en la aplicación de escritura durante aproximadamente 26 segundos.
3	Reiniciar el servidor	La elección fue activada por Pacemaker después del umbral de tiempo durante el cual el maestro no estaba disponible. El servidor en espera más elegible se promocionó como el nuevo maestro. Una vez que apareció el antiguo maestro después del reinicio, se volvió a agregar al clúster de la base de datos como un recurso de reserva. Si el cercado estuviera habilitado, el nodo no se habría agregado automáticamente al clúster. El servicio de la aplicación de escritor estuvo inactivo durante unos 26 segundos.
4	Detener el proceso de marcapasos	También detendrá el proceso de PostgreSQL y el servidor se marcará como fuera de línea. Se activará la elección y se elegirá un nuevo maestro. Hubo tiempo de inactividad en la aplicación de escritura.

Pruebas de aislamiento de red

Sl. No	Escenario de prueba	Observación
1	La red aísla el servidor en espera de otros servidores	El tráfico de Corosync se bloqueó en el servidor en espera. El servidor se marcó como fuera de línea y el servicio de PostgreSQL se apagó debido a la política de quórum. No hubo interrupciones en la aplicación del escritor.
2	La red aísla el servidor maestro de otros servidores (escenario de cerebro dividido)	El tráfico de Corosync se bloqueó en el servidor maestro. El servicio de PostgreSQL se apagó y el servidor maestro se marcó como fuera de línea debido a la política de quórum. Se eligió un nuevo maestro en la partición mayoritaria. Hubo un tiempo de inactividad en la aplicación de escritura.

Pruebas varias

Sl. No	Escenario de prueba	Observación
1	Degrade el clúster apagando todos los servidores en espera.	Cuando todos los servidores en espera fallaron, el servicio de PostgreSQL en el maestro se detuvo debido a la política de quórum. Después de esta prueba, cuando se encendieron todos los servidores en espera, se eligió un nuevo maestro. Hubo un tiempo de inactividad en la aplicación de escritura.
2	Apague aleatoriamente todos los servidores uno tras otro, empezando por el maestro, y tráigalos todos al mismo tiempo	Todos los servidores aparecieron y se unieron al clúster. Se eligió nuevo maestro. Hubo un tiempo de inactividad en la aplicación de escritura.

¿Es PAF la solución para la alta disponibilidad de PostgreSQL?

La conmutación por error automática de Postgres proporciona varias ventajas en el manejo de la alta disponibilidad (HA) de PostgreSQL en muchos casos de uso. PAF utiliza la conmutación por error de la dirección IP en lugar de reiniciar el modo de espera para conectarse al nuevo maestro durante un evento de conmutación por error. Esto resulta ventajoso en escenarios en los que el usuario no desea reiniciar los nodos en espera. PAF también necesita muy poca intervención manual y administra el estado general de todos los recursos de las bases de datos de Postgres. El único caso en el que la intervención manual es un requisito es en el caso de una divergencia de datos en la línea de tiempo en la que el usuario puede optar por utilizar pg_rewind.

En la Parte 1, analizamos las capacidades y el funcionamiento de la conmutación por error automática (PAF) de PostgreSQL de ClusterLabs, y en la Parte 2, analizaremos los mismos aspectos de alta disponibilidad utilizando el Administrador de replicación para clústeres de PostgreSQL (repmgr) de 2ndQuadrant. Asegúrese de volver a consultar la Parte 3, donde también cubriremos Patroni de Zalando y compararemos las tres soluciones de código abierto para ayudarlo a determinar la mejor opción para su aplicación.

En el blog de la Parte 1, analizamos las capacidades, las mejores prácticas y el funcionamiento de PAF de ClusterLabs, y en la publicación del blog de la Parte 2, analice el mismo tema de los aspectos de alta disponibilidad mediante el Administrador de replicación para clústeres de Postgresql (repmgr) de 2ndQuadrant. Asegúrese de consultar nuestra publicación de blog en la Parte 3, donde también cubriremos Patroni by Zalando y compararemos las tres soluciones de código abierto para ayudarlo a determinar las mejores prácticas y la opción ideal para sus aplicaciones comerciales.