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 de restablecimiento del 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 en 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 para restablecer el servicio después de una interrupción se denomina objetivo de tiempo de recuperación o 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 bien 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 un 99.99% y también requerir un RPO de 0, sin pérdida de datos en caso de falla 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 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, así, garantizar que cada transacción confirmada 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 podría 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 una 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 una latencia de menos de 10 milisegundos de diferencia). 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 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 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 bases 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 en las bases de datos pueden variar según el sistema de administración de bases de datos. A continuación, se mencionan algunas de las técnicas y herramientas que suelen utilizarse para implementar la alta disponibilidad en las bases de datos, las cuales 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 automatizada: 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 medidas de protección 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 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.
Recurso: 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 las 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, alta latencia, agotamiento de recursos y activan alertas o procedimientos automáticos de conmutación por error.
Copia de seguridad y restablecimiento: Las copias de seguridad se pueden usar para restablecer 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 distribuido, como etcd, Consul o Zookeeper, para coordinar y administrar el estado del clúster. Algunas de las funciones y los 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 bases de datos, y 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 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 utiliza para mejorar el rendimiento y la confiabilidad de las aplicaciones web distribuyendo las solicitudes entrantes en 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 realizando 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íncronos y asíncronos. De forma predeterminada, Patroni usa la replicación de transmisión asíncrona. Para requisitos estrictos de RPO, recomendamos usar 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 confirmar. 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. El servidor principal espera las confirmaciones del servidor en espera síncrono, lo que puede generar una mayor latencia y una menor capacidad de procesamiento debido al tiempo de ida y vuelta adicional. Esto puede reducir el rendimiento general del sistema, especialmente 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. 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 la instancia principal falla antes de que la instancia en espera se ponga al día. Es posible que los servidores en espera estén rezagados con respecto al servidor 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 se adapta a entornos en los que se priorizan el rendimiento y la menor latencia. Puedes configurar una solución mixta que incluya un clúster de tres nodos con una copia de seguridad síncrona en la misma región, pero en una zona o centro de datos cercano diferente, y una segunda copia de seguridad asíncrona en una región diferente o en un centro de datos más distante para protegerte contra posibles interrupciones regionales.