Alta disponibilidad para entornos PostgreSQL de calidad empresarial

La alta disponibilidad (HA) y la replicación de bases de datos es un tema importante de discusión para las tecnologías de bases de datos. Hay una serie de opciones informadas que se deben tomar para optimizar la replicación de PostgreSQL para que obtenga HA. En esta publicación, presentamos una descripción general del tema y cubrimos algunas opciones disponibles para obtener alta disponibilidad en PostgreSQL. Luego nos enfocaremos solo en una forma de implementar HA para postgres, usando Patterns.

En nuestras publicaciones de blog anteriores, discutimos las funciones disponibles para crear un entorno seguro de PostgreSQL y las herramientas disponibles para ayudarlo a establecer una estrategia de seguridad confiable. La serie de artículos está destinada a proporcionar una muestra de cómo se puede construir un entorno PostgreSQL empresarial de calidad utilizando herramientas de código abierto. Si desea ver esto implementado, consulte nuestra presentación del seminario web del 10 de octubre. ¡Creemos que le resultará útil e intrigante!

replicación de PostgreSQL

El primer paso para lograr una alta disponibilidad es asegurarse de no confiar en un solo servidor de base de datos: sus datos deben replicarse en al menos una réplica/esclavo en espera. La replicación de la base de datos se puede realizar utilizando las dos opciones disponibles con el software comunitario de PostgreSQL:

  1. Réplica de transmisión
  2. La replicación lógica es decodificación lógica

cuando nos acomodamos replicación de transmisión, una réplica en espera se conecta al maestro (primario) y transmite registros WAL desde él. La replicación de transmisión se considera uno de los métodos más seguros y rápidos para la replicación en PostgreSQL. Un servidor en espera se convierte en una réplica exacta del principal con un retraso potencialmente mínimo entre el principal y el en espera, incluso en servidores transaccionales muy ocupados. PostgreSQL le permite crear una replicación síncrona y asíncrona durante la transmisión. La replicación síncrona garantiza que un cliente reciba un mensaje correcto solo cuando el cambio no solo se confirma en el maestro, sino que también se replica correctamente en el servidor en espera. Dado que los servidores en espera pueden aceptar solicitudes de lectura de los clientes, podemos hacer un uso más eficiente de nuestra configuración de PostgreSQL al evitar que el maestro atienda las solicitudes de lectura y redirigirlas a las réplicas. Puede leer más sobre Streaming Replication en esta publicación de blog.

replicación lógica en PostgreSQL permite a los usuarios realizar una replicación selectiva de un subconjunto de las tablas que se encuentran en el maestro. Si bien la replicación de transmisión se implementa en PostgreSQL a nivel de bloque, donde cada base de datos en el maestro se replica en la replicación, que sigue siendo de solo lectura, la replicación lógica se adapta a escenarios únicos en los que necesita replicar una selección de tablas en una base de datos. y (opcionalmente) permitir la escritura directa a su esclavo. Un esclavo configurado con replicación lógica también se puede configurar para que lo repliquen varios maestros. Una situación en la que esto es útil es cuando necesita replicar datos de varias bases de datos de PostgreSQL en un solo servidor de PostgreSQL para tareas de informes y almacenamiento de datos.

Si bien es técnicamente posible emplear servidores en espera configurados con replicación lógica en un entorno HA, esta no es una buena práctica. Para tal uso, un servidor en espera debe poder tomar el lugar de otro servidor «transparentemente»: cuanto más se parezca al maestro, mejor. La replicación lógica abre la puerta para que diferentes datos se repliquen en diferentes servidores, y esto puede romper las cosas.

Aquí hay una lista de funciones integradas disponibles en PostgreSQL que están diseñadas para ayudarlo a obtener una alta disponibilidad:

  • Réplica de transmisión
  • Réplica de cascada
  • Modo de espera asíncrono
  • Modo de espera síncrono
  • Modo de espera cálido
  • Modo de espera cálido
  • pg_wind y pg_basebackup

La falla automática es una estrategia siempre activa

Existen muchas más soluciones de código abierto que pueden ayudarlo a lograr una alta disponibilidad con PostgreSQL, especialmente durante momentos críticos, cuando un maestro (servidor principal) deja de estar disponible. Aquí hay una lista de algunas de estas soluciones de código abierto creadas para PostgreSQL:

  1. Mecenas
  2. estolón
  3. repmgr
  4. Conmutación por error automática de PostgreSQL (PAF)
  5. pglookout
  6. pg Pool-II

Sin embargo, las soluciones HA disponibles para PostgreSQL no se limitan solo a la lista anterior. Nos interesaría saber qué ha implementado como solución HA en la sección de comentarios a continuación.

En nuestro próximo seminario web, le mostraremos un clúster de replicación de PostgreSQL creado con Patrons y cómo proporciona una conmutación por error transparente que es transparente para la aplicación.

Mecenas

Patronos es un Marco/modelo de gestión de clústeres de PostgreSQL que mira y habla con el Dconsenso distribuido almacenar clave-valor y decidir sobre el estado del racimo Comenzó como un tenedor gobernador proyecto. Un clúster de usuarios de PostgreSQL se compone de PostgreSQL muy individual instancias que operan en bare metal, contenedores o maquinas virtuales. En nuestra configuración usamos eccd para la gestión de consenso, que gestiona la elección del líder y decide el líder entre un grupo de servidores que son compartidos por la red. Esta gestión de consenso distribuido también se puede lograr utilizando otras tecnologías, como ZooKeeper y Cónsul. En el caso de una conmutación por error, Patrons promueve al esclavo que ha sido asignado como líder por almacenes clave-valor de consenso similares a eccd. Tenga en cuenta que cuando instalamos la replicación asíncrona, tenemos una opción para especificar maximum_lag_on_failover para limitar la promoción de un esclavo que se retrasa más de este valor.

Aquí hay un esquema de la arquitectura Patroni:

Principales ventajas de los Patronos:

  1. Supervisión continua y conmutación por error automática
  2. Cambio manual/planificado con un solo comando
  3. Automatización integrada para devolver un nodo fallido al clúster nuevamente.
  4. API REST para toda la configuración del clúster y otras herramientas.
  5. Proporciona infraestructura para la conmutación por error de aplicaciones transparente
  6. Consentimiento distribuido para todas las acciones y configuraciones.
  7. Integración con el perro guardián de Linux para prevenir el síndrome del cerebro dividido.
Si te ha resultado útil este post…

Asegúrese de disfrutar nuestro seminario web del 10 de octubre, donde demostraremos en vivo cómo crear un entorno PostgreSQL de alta calidad para toda la empresa con herramientas de código abierto. Si haces la presentación en vivo, también tienes la oportunidad de hacer preguntas al equipo.

En la próxima publicación de blog de esta serie, cubriremos la escalabilidad de nuestra solución y cómo acomodar un aumento en el tráfico manteniendo la calidad del servicio. ¡Nos estamos acercando a un entorno empresarial de calidad con herramientas de código abierto!

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario