En esta página, se describe la alta disponibilidad y las herramientas que recomendamos usar. Estas herramientas también admiten la configuración de HA para clústeres habilitados para la encriptación de datos transparente (TDE).
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 lograr una disponibilidad del 99.99%, tu base de datos no puede estar inactiva por más de 52.6 minutos por año o 4.38 minutos por mes. El tiempo para 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 la 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 RTO y RPO. Por ejemplo, para una carga de trabajo determinada, puedes establecer el SLO en 99.99% y también requerir un RPO de 0, sin pérdida de datos en ninguna falla, y un RTO de 30 segundos. Para otra carga de trabajo, puedes establecer el SLO en 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 requisitos más estrictos de RPO y RTO, 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 para garantizar que cada transacción confirmada en la 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 de tu clúster, la replicación síncrona puede afectar el tiempo de respuesta de las transacciones, y puedes optar por arriesgarte a una pequeña pérdida de datos. Por ejemplo, puedes tener un RPO distinto de cero a cambio de una latencia transaccional más baja si implementas la alta disponibilidad con replicación asíncrona en lugar de 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 dentro de un solo centro de datos o entre centros de datos que están cerca (decenas de km de distancia o <10 milisegundos de latencia de distancia). Sin embargo, ten en cuenta que esta documentación usa la replicación síncrona como 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 km de distancia, o a decenas o cientos de 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 a 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é 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 usan para implementar la alta disponibilidad para las bases de datos pueden variar según el sistema de administración de bases de datos. Las siguientes son 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: La replicación de 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 automática: 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 de modo que las solicitudes de la aplicación lleguen al nodo principal nuevo.
Continuidad de los datos: Se implementan protecciones para proteger 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 trabajen 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.
Respaldo: Son métodos para volver 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: La distribución de solicitudes de bases 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áticos.
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 corrupción de datos o falla catastrófica.
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 distribuido , como etcd, Consul o Zookeeper, para coordinar y administrar el estado del clúster. Algunas 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 instancias de servidor de bases de datos, y administra su estado, conmutaciones por error y replicación para garantizar la 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 distribuida (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 el balanceo de cargas y el proxy de aplicaciones basadas en TCP y HTTP, y se usa para mejorar el rendimiento y la confiabilidad de las aplicaciones web mediante la distribución de solicitudes entrantes en varios servidores. HAProxy ofrece balanceo de cargas mediante la distribución del tráfico de red en 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 modos síncrono y asíncrono. De forma predeterminada, Patroni usa la replicación de transmisión asíncrona. Para 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 que las transacciones se escriban en la principal y en al menos una en espera síncrona antes de confirmarlas. La replicación síncrona garantiza que no se pierdan datos en caso de falla principal, lo que proporciona una gran durabilidad y coherencia de los datos. La principal espera las confirmaciones de la en espera síncrona, lo que puede generar una mayor latencia y una capacidad de procesamiento potencialmente menor debido al tiempo de ida y vuelta adicional. Esto puede reducir la capacidad de procesamiento general del sistema, en especial, con una carga 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 principal envía registros WAL a las 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 principal falla antes de que la en espera se ponga al día. Las en espera pueden estar detrás de la principal, lo que genera posibles 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 priorizan el rendimiento y la latencia más baja. Puedes configurar una solución mixta que implique tener un clúster de tres nodos con una en espera síncrona en la misma región, pero en una zona o centro de datos cercano diferente, y una segunda en espera asíncrona en una región diferente o un centro de datos más distante para protegerte contra posibles interrupciones regionales.