En esta página se describe la alta disponibilidad y las herramientas que recomendamos usar.
Acerca de la resiliencia de los datos
La resiliencia de los datos se puede definir en términos de disponibilidad, tiempo de restauración del servicio y pérdida de datos. La disponibilidad suele medirse en términos de tiempo de actividad y se expresa como el porcentaje de tiempo que la base de datos está disponible. Por ejemplo, para conseguir una disponibilidad del 99,99 %, tu base de datos no puede estar inactiva durante más de 52,6 minutos al año o 4,38 minutos al mes. El tiempo que se tarda en restaurar el servicio después de una interrupción se denomina objetivo de tiempo de recuperación (RTO). La cantidad de pérdida de datos aceptable debido a una interrupción se denomina objetivo de punto de recuperación (RPO) y se expresa como el tiempo durante el cual se pierden las transacciones. Por ejemplo, un RPO de 10 minutos significa que, en caso de fallo, podrías perder hasta 10 minutos de datos.
Es habitual definir un objetivo de disponibilidad, u objetivo de nivel de servicio, junto con los objetivos de tiempo de recuperación y punto de recuperación. Por ejemplo, en una carga de trabajo determinada, puedes definir el SLO en el 99,99 % y también requerir un RPO de 0, es decir, que no se pierdan datos en caso de fallo, y un RTO de 30 segundos. En otra carga de trabajo, puedes definir el SLO en el 99,9%, el RPO en 5 minutos y el RTO en 10 minutos.
Puedes implementar la resiliencia básica de la base de datos con copias de seguridad de la base de datos. AlloyDB Omni admite copias de seguridad con pgBackRest y también archiva los archivos de registro de escritura anticipada (WAL) de la base de datos para minimizar la pérdida de datos. Con este enfoque, si tu base de datos principal deja de funcionar, se puede restaurar a partir de una copia de seguridad con un RPO de minutos y un RTO de minutos u horas, en función del tamaño de la base de datos.
Si tienes requisitos de RPO y RTO más estrictos, puedes configurar AlloyDB Omni en una configuración de alta disponibilidad mediante Patroni. En esta arquitectura, hay una base de datos principal y dos bases de datos de reserva o réplica. Puedes configurar AlloyDB Omni para que use la replicación de streaming estándar de PostgreSQL y, de esta forma, asegurarte de que cada transacción que se confirme en la base de datos principal se replique de forma síncrona en ambas bases de datos de reserva. Esto proporciona un RPO de cero y un RTO de menos de 60 segundos en la mayoría de los casos de fallo.
En función de la configuración de tu clúster, la replicación síncrona puede afectar al tiempo de respuesta de las transacciones, y puedes asumir el riesgo de perder una pequeña cantidad de datos. Por ejemplo, puedes tener un RPO distinto de cero a cambio de una latencia de transacción más baja si implementas una alta disponibilidad con una replicación asíncrona en lugar de una síncrona. Debido al posible impacto de la replicación síncrona en la latencia de las transacciones, las arquitecturas de alta disponibilidad casi siempre se implementan en un solo centro de datos o entre centros de datos que están cerca entre sí (a decenas de kilómetros o con una latencia de menos de 10 milisegundos). Sin embargo, ten en cuenta que esta documentación usa la replicación síncrona de forma predeterminada.
Para la recuperación ante desastres, que es la protección contra la pérdida de un centro de datos o de una región en la que hay varios centros de datos cerca, AlloyDB Omni se puede configurar con una replicación de streaming asíncrona de la región principal a una secundaria, que suele estar a cientos o miles de kilómetros, o a decenas o cientos de milisegundos. En esta configuración, la región principal se configura con la replicación de streaming síncrona entre las bases de datos principal y de espera de la región, y la replicación de streaming asíncrona se configura desde la región principal a una o varias regiones secundarias. AlloyDB Omni se puede configurar en la región secundaria con varias instancias de base de datos para asegurarse de que esté protegido inmediatamente después de una conmutación por error desde la región principal.
Cómo funciona la alta disponibilidad
Las técnicas y herramientas específicas que se utilizan para implementar la alta disponibilidad de las bases de datos pueden variar en función del sistema de gestión de bases de datos. A continuación, se indican algunas de las técnicas y herramientas que se suelen usar para implementar la alta disponibilidad en bases de datos, que pueden variar en función del sistema de gestión de bases de datos:
Redundancia: replicar tu base de datos en varios servidores o regiones geográficas te ofrece opciones de conmutación por error si una instancia principal deja de funcionar.
Conmutación por error automatizada: mecanismo para detectar fallos y cambiar sin problemas a una réplica correcta, lo que minimiza el tiempo de inactividad. Las consultas se enrutan para que las solicitudes de la aplicación lleguen al nuevo nodo principal.
Continuidad de los datos: se implementan medidas de protección para proteger la integridad de los datos durante los fallos. Esto incluye técnicas de replicación y comprobaciones de coherencia de los datos.
Clústeres: los clústeres implican agrupar varios servidores de bases de datos para que funcionen juntos como un único sistema. De esta forma, todos los nodos del clúster están activos y gestionan las solicitudes, lo que proporciona balanceo de carga y redundancia.
Reserva: métodos para volver a la arquitectura original usando nodos primarios y de réplica previos a la conmutación por error en sus capacidades originales.
Balanceo de carga: distribuir las solicitudes de la base de datos entre varias instancias mejora el rendimiento y gestiona el aumento del tráfico.
Monitorización y alertas: las herramientas de monitorización detectan problemas como fallos del servidor, alta latencia o agotamiento de recursos, y activan alertas o procedimientos de conmutación por error automática.
Copia de seguridad y restauración: las copias de seguridad se pueden usar para restaurar bases de datos a un estado anterior en caso de corrupción de datos o fallos catastróficos.
Agrupación de conexiones (opcional): optimiza el rendimiento y la escalabilidad de las aplicaciones que interactúan con tus bases de datos.
Herramientas de alta disponibilidad
Patroni es una herramienta de gestión de clústeres de código abierto para bases de datos PostgreSQL diseñada para gestionar y automatizar la alta disponibilidad de los clústeres de PostgreSQL. Patroni usa varios sistemas de consenso distribuido, como etcd, Consul o Zookeeper, para coordinar y gestionar el estado del clúster. Entre las principales funciones y componentes de Patroni se incluyen la alta disponibilidad con conmutación por error automática, la elección del líder, la replicación y la recuperación. Patroni se ejecuta junto con el servicio PostgreSQL en las instancias del servidor de bases de datos y gestiona su estado, las conmutaciones por error y la replicación para garantizar una alta disponibilidad y fiabilidad.
Patroni usa un sistema de consenso distribuido para almacenar metadatos y gestionar el clúster. En esta guía, usamos un almacén de configuración distribuido (DCS) llamado etcd. Uno de los usos de etcd es almacenar y recuperar información de sistemas distribuidos, como la configuración, el estado y el estado actual, lo que garantiza una configuración coherente en todos los nodos.
High Availability Proxy (HAProxy) es un software de código abierto que se usa para equilibrar la carga y hacer de proxy de aplicaciones basadas en TCP y HTTP. Se utiliza para mejorar el rendimiento y la fiabilidad de las aplicaciones web distribuyendo las solicitudes entrantes en varios servidores. HAProxy ofrece balanceo de carga distribuyendo el tráfico de red entre varios servidores. HAProxy también mantiene el estado de los servidores backend a los que se conecta realizando comprobaciones de estado. Si un servidor no supera una comprobación del estado, HAProxy deja de enviarle tráfico hasta que vuelva a superar las comprobaciones del estado.
Consideraciones sobre la replicación síncrona y asíncrona
En un clúster de PostgreSQL gestionado por Patroni, la replicación se puede configurar en modo síncrono y asíncrono. De forma predeterminada, Patroni usa la replicación de streaming asíncrona. Si tienes requisitos de RPO estrictos, te recomendamos que uses la replicación síncrona.
La replicación síncrona en PostgreSQL asegura la coherencia de los datos esperando a que las transacciones se escriban tanto en la instancia principal como en al menos una instancia de espera síncrona antes de confirmarlas. La replicación síncrona asegura que los datos no se pierdan en caso de que se produzca un fallo en el servidor principal, lo que proporciona una gran durabilidad y coherencia de los datos. La principal espera las confirmaciones de la secundaria síncrona, lo que puede provocar una latencia mayor y un rendimiento potencialmente inferior debido al tiempo de ida y vuelta adicional. Esto puede reducir el rendimiento general del sistema, especialmente cuando la carga es elevada.
La replicación asíncrona permite que las transacciones se confirmen en el clúster principal sin esperar las confirmaciones de los clústeres de reserva. El primario envía registros WAL a los secundarios, que los aplican de forma asíncrona. Este enfoque asíncrono reduce la latencia de escritura y mejora el rendimiento, pero conlleva el riesgo de pérdida de datos si la instancia principal falla antes de que la de espera se haya puesto al día. Las réplicas pueden estar por detrás de la principal, lo que puede provocar incoherencias durante la conmutación por error.
La elección entre la replicación síncrona y asíncrona en un clúster de Patroni depende de los requisitos específicos de durabilidad, coherencia y rendimiento de los datos. La replicación síncrona es preferible en situaciones en las que la integridad de los datos y la pérdida mínima de datos son fundamentales, mientras que la replicación asíncrona se adapta a entornos en los que se prioriza el rendimiento y una latencia más baja. Puedes configurar una solución mixta que incluya un clúster de tres nodos con una réplica en espera síncrona en la misma región, pero en una zona o centro de datos cercano diferente, y una segunda réplica en espera asíncrona en otra región o en un centro de datos más alejado para protegerte frente a posibles interrupciones regionales.