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

¿Está implementando PostgreSQL en la nube y quiere comprender sus opciones para lograr una alta disponibilidad? En nuestra publicación de blog anterior, Gestión de alta disponibilidad en PostgreSQL - Parte I, discutimos las capacidades y el funcionamiento de la conmutación por error automática (PAF) de PostgreSQL de ClusterLabs. En la Parte II, le presentamos una herramienta alternativa de código abierto, Replication Manager de 2ndQuadrant, seguida de cerca por la Parte III, donde nos sumergimos en nuestra tercera alternativa, Patroni by Zalando.

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 III:Patroni

Administrador de replicación (repmgr)

repmgr es un conjunto de herramientas de código abierto desarrollado por 2ndQuadrant para administrar la replicación y la conmutación por error de sus clústeres de PostgreSQL. Proporciona las herramientas para instalar, configurar, administrar y monitorear la replicación de PostgreSQL, y también le permite realizar tareas de conmutación manual y conmutación por error mediante la utilidad repmgr. Esta herramienta gratuita admite y mejora la replicación de transmisión integrada de PostgreSQL.

Replication Manager proporciona dos herramientas principales para administrar la replicación y la conmutación por error de PostgreSQL.

repmgr

Una utilidad de interfaz de línea de comandos que le permite realizar varias tareas administrativas.
repmgr le permite configurar servidores en espera, promover servidores en espera, realizar un cambio y monitorear el estado de su clúster de PostgreSQL.
También proporciona la opción de ejecución en seco para casi todos los comandos administrativos.

repmgrd

Este es el demonio que:

Supervisa activamente los clústeres de PostgreSQL y realiza las acciones necesarias según el estado del clúster.
Realiza una conmutación por error automática en caso de que el nodo principal se caiga al promover el respaldo más elegible como el nuevo principal.
Proporciona una opción para monitorear y almacenar los datos relacionados con el rendimiento de la replicación.
Proporciona notificaciones al invocar los scripts de usuario para eventos registrados.

Cómo funciona

repmrg no solo administra la replicación de clústeres de PostgreSQL, sino que también tiene capacidades para configurar los servidores en espera para la replicación. Después de la instalación inicial, debemos realizar cambios en el archivo de configuración de repmgr (repmgr.conf) con los detalles requeridos en cada servidor. Cuando se configura un servidor, debe registrarse con repmgr mediante el comando de registro primario/en espera de repmgr. En primer lugar, se configura y registra el nodo principal. Luego, los servidores en espera se crean y configuran usando el comando repmgr standby clone que clona el nodo en espera de PostgreSQL desde otro servidor PostgreSQL.

Replication Manager utiliza la función de extensiones de PostgreSQL y crea su propio esquema en la base de datos del clúster para almacenar la información relacionada con el clúster. La instalación de la extensión y la creación del esquema se realizan durante el registro del servidor principal mediante repmgr. Una vez que se completa la configuración, las operaciones administrativas manuales, como promover, seguir, cambiar, etc., se pueden realizar mediante la utilidad repmgr. Para la operación de conmutación, se requiere la configuración de SSH sin contraseña entre los nodos.

La conmutación por error automática se puede configurar mediante repmgrd. repmgrd requiere que se cargue una biblioteca compartida 'repmgr' al momento de iniciar el servidor PostgreSQL. El nombre de la biblioteca debe mencionarse en shared_preload_libraries parámetro de configuración en el archivo postgresql.conf. Además, para que repmgrd funcione, failover=automatic el parámetro debe configurarse en el archivo repmgr.conf. Una vez que se establecen todos estos parámetros, repmgrd daemon comienza a monitorear activamente el clúster. Si hay alguna falla en el nodo principal, intentará volver a conectarse varias veces. Cuando fallan todos los intentos de conectarse a la principal, repmgrd elige la reserva más elegible como la nueva principal.

repmgr también admite notificaciones de eventos. Tiene un conjunto de eventos predefinidos y almacena cada ocurrencia de estos eventos en la tabla repmgr.events. repmgr permite que las notificaciones de eventos se pasen a un programa o script definido por el usuario que puede realizar más acciones, como enviar un correo electrónico o activar cualquier alerta. Esto se hace configurando el event_notification_command parámetro en repmgr.conf.

¿Cómo maneja el escenario del cerebro dividido?

repmgr aborda escenarios de cerebro dividido usando la ubicación parámetro, donde cada nodo debe especificar el parámetro de ubicación en función del centro de datos en el que se coloca. En caso de división de la red, repmgr garantizará la promoción del nodo que se encuentra en la misma ubicación que el principal. Si no encuentra ningún nodo en esa ubicación, no promocionará ningún nodo en ninguna ubicación.

También gestiona el aislamiento de la red en caso de que haya un número par de servidores en un clúster. Esto se hace usando un nodo adicional llamado servidor testigo. El servidor testigo es un nodo que se considera solo para el recuento de votos de la mayoría. No habrá instalación de PostgreSQL en ese servidor y, por lo tanto, no tendrá ningún papel en la replicación.

¿Hay algún requisito de configuración?

repmgr requerirá una base de datos dedicada y un usuario con privilegios de superusuario. Sin embargo, también hay una opción para proporcionar un superusuario si no está dispuesto a darle acceso de superusuario al usuario repmgr.
Si desea que repmgr copie los archivos de configuración que se encuentran fuera del directorio de datos de PostgreSQL y/o para probar la funcionalidad de cambio, también necesitará conexiones SSH sin contraseña entre ambos servidores, y rsync debe estar instalado.
Si pretende utilizar comandos basados en servicios que no sean pg_ctl (que repmgr utiliza de forma predeterminada) para iniciar, detener, recargar y reiniciar, puede especificarlos en repmgr archivo de configuración (repmgr.conf).

Los parámetros de configuración básicos requeridos en el archivo de configuración de repmgr son los siguientes:

id_nodo (int) – Un entero único mayor que cero que identifica el nodo.node_name (cadena) – Se recomienda una cadena arbitraria (pero única), utilizando el nombre de host del servidor u otro identificador asociado inequívocamente con el servidor para evitar confusiones.

conninfo (cadena) – Información de conexión de la base de datos como una cadena conninfo. Todos los servidores del clúster deben poder conectarse al nodo local mediante esta cadena.

directorio_datos (cadena) – El directorio de datos del nodo. Repmgr lo necesita para realizar operaciones cuando la instancia de PostgreSQL no se está ejecutando y no hay otra forma de determinar el directorio de datos.

Ventajas de repmgr

Repmgr proporciona utilidades que ayudan a configurar los nodos principales y en espera y configurar la replicación.
No utiliza ningún puerto adicional para la comunicación. Si desea realizar el cambio, solo entonces requerirá que se configure SSH sin contraseña.
Proporciona notificación al invocar los scripts de usuario para los eventos registrados.
Realiza una conmutación por error automática en caso de falla del servidor principal.

Contras de repmgr

repmgr no detecta si el modo de espera está mal configurado con un nodo desconocido o inexistente en la configuración de recuperación. El nodo se mostrará como en espera incluso si se está ejecutando sin conectarse al nodo primario/en espera en cascada.
No se puede recuperar el estado de otro nodo desde un nodo donde el servicio de PostgreSQL está inactivo. Por lo tanto, no proporciona una solución de control distribuido.
No maneja la recuperación del estado de los nodos individuales.

Gestión de alta disponibilidad en #PostgreSQL - Parte II:Herramienta repmgr de código abierto Haga clic para twittear

Escenarios de prueba de alta disponibilidad

Realizamos algunas pruebas en la gestión de alta disponibilidad de PostgreSQL mediante repmgr. 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ó 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	El servidor en espera se marcó como fallido. No hubo interrupción en la aplicación del escritor. Se requirió una intervención manual para iniciar el proceso de PostgreSQL nuevamente.
2	Detenga el proceso de PostgreSQL	El servidor en espera se marcó como fallido. No hubo interrupción en la aplicación del escritor. Se requirió una intervención manual para iniciar el proceso de PostgreSQL nuevamente.
3	Reiniciar el servidor	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 interrupciones en la aplicación del escritor.
4	Detener el proceso repmgrd	El servidor en espera no formará parte de la situación de conmutación por error automatizada. Se encontró que el servicio PostgreSQL se estaba ejecutando. 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	repmgrd inició la comprobación de estado de la conexión del servidor principal en todos los servidores de reserva durante un intervalo fijo. Cuando fallaron todos los reintentos, se activó una elección en todos los servidores en espera. Como resultado de la elección, se promovió el standby que tenía el último LSN recibido. Los servidores en espera que perdieron la elección esperarán la notificación del nuevo nodo maestro y la seguirán una vez que la reciban. Hubo un tiempo de inactividad en la aplicación de escritura. Se requirió una intervención manual para iniciar el proceso de PostgreSQL nuevamente.
2	Detenga el proceso de PostgreSQL y tráigalo inmediatamente después de que caduque la verificación de estado	repmgrd inició la comprobación de estado de la conexión del servidor principal en todos los servidores de reserva durante un intervalo fijo. Cuando fallaron todos los reintentos, se activó una elección en todos los nodos en espera. Sin embargo, el maestro recién elegido no notificó a los servidores de reserva existentes ya que el maestro anterior había regresado. El clúster quedó en un estado indeterminado y se requirió intervención manual.
3	Reiniciar el servidor	repmgrd inició la elección cuando falló la verificación del estado de la conexión maestra en todos los servidores en espera. Se promovió el modo de espera apto. Cuando este servidor volvió, no se unió al clúster y se marcó como fallido. Se ejecutó el comando repmgr node rejoin para volver a agregar el servidor al clúster. Hubo tiempo de inactividad en la aplicación de escritura.
4	Detener el proceso repmgr	El servidor principal no formará parte de la situación de conmutación por error automatizada. Se encontró que el servicio PostgreSQL se estaba ejecutando. No hubo interrupciones en la aplicación del escritor.

Pruebas de aislamiento de red

Sl. No	Escenario de prueba	Observación
1	La red aísla el servidor principal de otros servidores (todos tienen el mismo valor de ubicación en la configuración de repmgr)	repmgrd inició la elección cuando falló la verificación del estado de la conexión maestra en todos los servidores en espera. Se promovió el modo de espera elegible, pero el proceso de PostgreSQL aún se estaba ejecutando en el nodo principal anterior. Había dos nodos ejecutándose como maestro. Se requirió intervención manual después de que se corrigió el aislamiento de la red.
2	La red aísla el servidor principal de otros servidores (los servidores en espera tienen el mismo valor para la ubicación, pero el principal tenía un valor diferente para la ubicación en la configuración de repmgr)	repmgrd inició la elección cuando la comprobación del estado de la conexión maestra falló en todos los servidores en espera. Sin embargo, no se eligió un nuevo maestro ya que los servidores en espera tenían una ubicación diferente a la del principal. repmgrd pasó al modo de monitoreo degradado. PostgreSQL se estaba ejecutando en todos los nodos y solo había un maestro en el clúster.

Inferencia

repmgr proporciona varios comandos para configurar y monitorear la replicación de PostgreSQL. Tiene muchas funciones y también facilita el trabajo del administrador de la base de datos (DBA). Sin embargo, no es una herramienta de administración de alta disponibilidad completa, ya que no administrará los recursos. Se requiere una intervención manual para garantizar que el recurso esté en el estado adecuado.

Entonces, en esta publicación, analizamos las capacidades y el funcionamiento de Replication Manager de 2ndQuadrant. En nuestra próxima publicación, discutiremos los mismos aspectos de alta disponibilidad usando Patroni by Zalando. Para los usuarios que buscan automatizar su alta disponibilidad en la nube, consulte nuestras soluciones completamente administradas de PostgreSQL en Azure y PostgreSQL en AWS.