En esta página, se describe la alta disponibilidad y las herramientas que recomendamos usar.
Acerca de la resiliencia de los datos
Puedes pensar en la resiliencia de los datos en términos de disponibilidad, tiempo para restablecer el servicio y pérdida de datos. Por lo general, la disponibilidad se mide 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 alcanzar una disponibilidad del 99.99%, tu base de datos no puede estar inactiva durante más de 52.6 minutos por año o 4.38 minutos por mes. El tiempo que se demora en restablecer 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 la cantidad de tiempo durante el cual se pierden las transacciones. Por ejemplo, un RPO de 10 minutos significa que, en caso de falla, podrías perder hasta 10 minutos de datos.
Es común establecer un objetivo de disponibilidad o un objetivo de nivel de servicio (SLO) junto con objetivos para el RTO y el RPO. Por ejemplo, para una carga de trabajo determinada, puedes establecer el SLO en 99.99% y, además, requerir un RPO de 0, sin pérdida de datos en ningún error, y un RTO de 30 segundos. Para otra carga de trabajo, puedes establecer el SLO en un 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 restablecer desde una copia de seguridad con un RPO de minutos y un RTO de minutos a horas, según el tamaño de la base de datos.
Para cumplir con requisitos de RPO y RTO más estrictos, puedes configurar AlloyDB Omni en una configuración de alta disponibilidad con Patroni. En esta arquitectura, hay una base de datos principal y dos bases de datos en espera o de réplica. Puedes configurar AlloyDB Omni para que use la replicación de transmisión estándar de PostgreSQL y garantizar que cada transacción que se confirme en la base de datos principal se replique de forma síncrona en ambas bases de datos en espera. Esto proporciona un RPO de cero y un RTO de menos de sesenta segundos para la mayoría de las situaciones de falla.
Según la configuración del clúster, la replicación síncrona puede afectar el tiempo de respuesta de las transacciones, y puedes optar por arriesgarte a perder una pequeña cantidad de datos. Por ejemplo, puedes tener un RPO distinto de cero a cambio de una latencia transaccional más baja si implementas alta disponibilidad con replicación asíncrona en lugar de síncrona. Debido al impacto potencial de la replicación síncrona en la latencia de las transacciones, las arquitecturas de alta disponibilidad casi siempre se implementan dentro de un solo centro de datos o entre centros de datos que están cerca (a decenas de kilómetros de distancia o con menos de 10 milisegundos de latencia). Sin embargo, ten en cuenta que en esta documentación se 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 una región en la que hay varios centros de datos cercanos, AlloyDB Omni se puede configurar con replicación de transmisión asíncrona desde la región principal a una región secundaria, por lo general, a cientos o miles de kilómetros de distancia, o de 10 a 100 milisegundos de distancia. En esta configuración, la región principal se configura con replicación de transmisión síncrona entre las bases de datos principal y en espera dentro de la región, y la replicación de transmisión asíncrona se configura desde la región principal hasta una o más regiones secundarias. AlloyDB Omni se puede configurar en la región secundaria con varias instancias de base de datos para garantizar que esté protegida 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 usan para implementar la alta disponibilidad en las bases de datos pueden variar según el sistema de administración de bases de datos. A continuación, se indican algunas de las técnicas y herramientas que suelen participar en la implementación de la alta disponibilidad para las bases de datos, que pueden variar según el sistema de administración de bases de datos:
Redundancia: Replicar tu base de datos en varios servidores o regiones geográficas proporciona opciones de conmutación por error si una instancia principal deja de funcionar.
Conmutación por error automatizada: Es un mecanismo para detectar fallas y cambiar sin problemas a una réplica en buen estado, lo que minimiza el tiempo de inactividad. Las consultas se enrutan para que las solicitudes de la aplicación lleguen al nodo principal nuevo.
Continuidad de los datos: Se implementan protecciones para garantizar la integridad de los datos durante las fallas. Esto incluye técnicas de replicación y verificaciones de coherencia de los datos.
Agrupamiento en clústeres: El agrupamiento en clústeres implica agrupar varios servidores de bases de datos para que funcionen juntos como un solo sistema. De esta manera, todos los nodos del clúster están activos y controlan las solicitudes, lo que proporciona balanceo de cargas y redundancia.
Resguardo: Métodos para recurrir a la arquitectura original con nodos principales y de réplica anteriores a la conmutación por error y con sus capacidades originales
Balanceo de cargas: Distribuir las solicitudes de la base de datos en varias instancias mejora el rendimiento y controla el aumento del tráfico.
Supervisión y alertas: Las herramientas de supervisión detectan problemas como fallas del servidor, latencia alta, agotamiento de recursos y activan alertas o procedimientos de conmutación por error automática.
Copia de seguridad y restablecimiento: Las copias de seguridad se pueden usar para restablecer las bases de datos a un estado anterior en caso de daños en los datos o fallas catastróficas.
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 administración de clústeres de código abierto para bases de datos de PostgreSQL diseñada para administrar y automatizar la alta disponibilidad de los clústeres de PostgreSQL. Patroni usa varios sistemas de consenso distribuidos, como etcd, Consul o Zookeeper, para coordinar y administrar el estado del clúster. Algunas de las funciones y componentes clave de Patroni incluyen alta disponibilidad con conmutación por error automática, elección de líder, replicación y recuperación. Patroni se ejecuta junto con el servicio de PostgreSQL en las instancias del servidor de la base de datos, lo que administra su estado, las conmutaciones por error y la replicación para garantizar una alta disponibilidad y confiabilidad.
Patroni usa un sistema de consenso distribuido para almacenar metadatos y administrar 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 balancear cargas y enviar solicitudes de proxy a aplicaciones basadas en TCP y HTTP. Se usa para mejorar el rendimiento y la confiabilidad de las aplicaciones web distribuyendo las solicitudes entrantes entre varios servidores. HAProxy ofrece balanceo de cargas distribuyendo el tráfico de red entre varios servidores. HAProxy también mantiene el estado de los servidores de backend a los que se conecta mediante la realización de verificaciones de estado. Si un servidor falla en una verificación de estado, HAProxy deja de enviarle tráfico hasta que vuelva a pasar las verificaciones de estado.
Consideraciones sobre la replicación síncrona y asíncrona
En un clúster de PostgreSQL administrado por Patroni, la replicación se puede configurar en los modos síncrono y asíncrono. De forma predeterminada, Patroni usa la replicación de transmisión asíncrona. Para cumplir con requisitos estrictos de RPO, te recomendamos que uses la replicación síncrona.
La replicación síncrona en PostgreSQL garantiza la coherencia de los datos, ya que espera a que las transacciones se escriban en la base de datos principal y en, al menos, una base de datos en espera síncrona antes de confirmarlas. La replicación síncrona garantiza que los datos no se pierdan en caso de una falla principal, lo que proporciona una gran durabilidad y coherencia de los datos. La instancia principal espera las confirmaciones de la instancia en espera síncrona, lo que puede generar una mayor latencia y, posiblemente, una menor capacidad de procesamiento debido al tiempo de ida y vuelta adicional. Esto puede reducir la capacidad de procesamiento general del sistema, en especial cuando la carga es alta.
La replicación asíncrona permite que las transacciones se confirmen en el clúster principal sin esperar las confirmaciones de los clústeres en espera. La instancia principal envía registros de WAL a las instancias en espera, 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 instancia en espera se haya actualizado. Las instancias en espera podrían estar detrás de la principal, lo que podría generar 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 es adecuada para entornos en los que se priorizan el rendimiento y una latencia más baja. Puedes configurar una solución mixta que implique tener un clúster de tres nodos con una instancia en espera síncrona en la misma región, pero en una zona o un centro de datos cercanos diferentes, y una segunda instancia en espera asíncrona en una región diferente o en un centro de datos más distante para protegerte contra posibles interrupciones regionales.