En esta página, se describe la alta disponibilidad y las herramientas que recomendamos usar.
Información 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 durante más de 52.6 minutos por año o 4.38 minutos por mes. El tiempo de restablecimiento del 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 o 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 de RTO y RPO. Por ejemplo, para una carga de trabajo determinada, puedes establecer el SLO en un 99.99% y, además, 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 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 las 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 falla la base de datos principal, 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 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 réplicas. Puedes configurar AlloyDB Omni para que use la replicación de transmisión estándar de PostgreSQL para 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 fallas.
Según la configuración de tu clúster, la replicación síncrona podría 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 de transacción 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 (a decenas de kilómetros de distancia o con menos de 10 milisegundos de latencia). Sin embargo, ten en cuenta que esta documentación usa la replicación síncrona como opción 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 la replicación de transmisión asíncrona de la región principal a una región secundaria, por lo general, a cientos o miles de kilómetros de distancia, o entre 10 y 100 milisegundos de diferencia. En esta configuración, la región principal se configura con la 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é protegida inmediatamente después de una conmutación por error de 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 estar involucradas 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 se cae una instancia principal.
Conmutación por error automática: 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 nuevo nodo principal.
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.
Agrupación en clústeres: La agrupación 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.
Conmutación por error: Son 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: 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á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.
Grupo 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 funciones y componentes clave de Patroni incluyen la 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 servidores de bases de datos y administra su estado, conmutación por error y replicación para garantizar 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 de salud y el estado actual, lo que garantiza una configuración coherente en todos los nodos.
El proxy de alta disponibilidad (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, que 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 verificaciones de estado. Si un servidor falla en una verificación de estado, HAProxy deja de enviarle tráfico hasta que vuelva a aprobar 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 modo 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 a que las transacciones se escriban en la principal y, al menos, en una réplica síncrona en espera antes de confirmarlas. La replicación síncrona garantiza que no se pierdan los datos en caso de falla principal, lo que proporciona una durabilidad y coherencia de los datos sólidas. El elemento principal espera los acuse de recibo del modo de espera síncrono, lo que puede generar una latencia más alta 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 con una carga alta.
La replicación asíncrona permite que las transacciones se confirmen en el clúster principal sin esperar confirmaciones de los clústeres de reserva. El nodo principal envía registros de WAL a los nodos 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 el elemento principal falla antes de que el elemento en espera se haya puesto al día. Los objetos en espera pueden estar detrás del principal, lo que puede generar inconsistencias 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 la latencia más baja. Puedes configurar una solución mixta que implique tener un clúster de tres nodos con un estado de espera síncrono en la misma región, pero en una zona o un centro de datos cercanos diferentes, y un segundo estado de espera asíncrono en una región diferente o un centro de datos más distante para protegerte contra posibles interrupciones regionales.