Protege tus datos con la replicación zonal

Selecciona una versión de la documentación:

En esta página, se describe la arquitectura de referencia de disponibilidad mejorada de AlloyDB Omni, que proporciona alta disponibilidad mediante la implementación de una o más réplicas de bases de datos dentro de la misma región que protege de las fallas a nivel del nodo o de la zona.

Casos de uso

Esta arquitectura de referencia de disponibilidad es adecuada para los siguientes casos de uso:

  • Aplicaciones esenciales para la empresa que requieren un RTO y un RPO más bajos.
  • Quieres implementar una réplica en otra zona o nodo que proporcione alta disponibilidad para tus bases de datos y proteja de las fallas de instancias, servidores y zonales.
  • Quieres protección contra errores del usuario y corrupción de datos (con copias de seguridad).

Cómo funciona la arquitectura de referencia

La disponibilidad mejorada se suma a la disponibilidad estándar agregando instancias de réplica de lectura dentro de la región para habilitar la alta disponibilidad (HA) que reduce el objetivo de tiempo de recuperación (RTO). Este enfoque también reduce el objetivo de punto de recuperación (RPO) al permitir la transmisión de cambios transaccionales a la réplica.

La alta disponibilidad en AlloyDB Omni utiliza al menos dos instancias de base de datos. Una instancia funciona como la base de datos principal, que admite operaciones de lectura y escritura. Las instancias restantes sirven como réplicas de lectura y operan en modo de solo lectura.

Los siguientes son conceptos importantes de HA:

  • La conmutación por error es el procedimiento durante una interrupción no planificada en la que falla la instancia principal o deja de estar disponible, y se activa la réplica en espera para asumir el modo principal (lectura y escritura). Este proceso se denomina promoción. Por lo general, en estas situaciones, cuando el servidor o la base de datos principal vuelven a estar en línea, se debe volver a compilar la base de datos y, luego, debe actuar como en espera. Para proporcionar un tiempo de actividad alto, se implementan mecanismos para que las conmutaciones por error sean automáticas.
  • Un cambio, también conocido como reversión de roles, es un procedimiento que se usa para cambiar los modos entre la base de datos principal y una de las bases de datos en espera, de modo que la principal se convierta en la base de datos en espera y la base de datos en espera se convierta en la principal. Por lo general, los cambios se realizan de forma controlada y correcta, y se pueden iniciar por varios motivos, por ejemplo, para permitir el tiempo de inactividad y la aplicación de parches de la base de datos principal anterior. Los cambios correctos deben permitir un cambio posterior sin necesidad de volver a crear una instancia de la nueva base de datos en espera ni otros aspectos de la configuración de replicación.

Opciones de alta disponibilidad

En los entornos de Kubernetes, para admitir la HA, puedes implementar AlloyDB Omni con operadores de Kubernetes de AlloyDB Omni operadores. Para obtener más información, consulta Administra la alta disponibilidad en Kubernetes.

Nota: Patroni y HAProxy son herramientas de terceros no comerciales y son compatibles con AlloyDB Omni.

Te recomendamos que tengas al menos dos bases de datos en espera para que la pérdida de una base de datos no afecte la alta disponibilidad del clúster. En ese modo, tienes al menos un par de HA en caso de conmutación por error o durante cualquier mantenimiento planificado de un nodo.

Para planificar el tamaño y la forma de tu implementación de AlloyDB Omni, consulta Planifica tu instalación de AlloyDB Omni en una VM.

Balanceadores de cargas

Otro mecanismo importante que ayuda a que los procedimientos de cambio y conmutación por error sean más fluidos es la presencia de un balanceador de cargas.

El operador de Kubernetes implementa su propio balanceador de cargas, que se comporta de manera similar, creando un servicio para la base de datos que apunta al balanceador de cargas para que esto sea transparente para el usuario.

Alta disponibilidad

Las bases de datos de réplica de lectura implementadas dentro de una región proporcionan alta disponibilidad si falla la base de datos principal. Cuando se produce una falla en la base de datos principal, la base de datos en espera se promueve para reemplazar la principal y la aplicación continúa con poca o ninguna interrupción.

Por lo general, se recomienda realizar verificaciones periódicas anuales o semestrales en forma de cambios para garantizar que todas las aplicaciones que dependen de estas bases de datos aún puedan conectarse y responder en un período adecuado.

La protección a nivel de la zona se puede lograr con cualquiera de los tipos de implementación colocando una de las réplicas de lectura en espera en una zona de disponibilidad diferente de la base de datos principal.

Un beneficio adicional de tener réplicas de lectura es la capacidad de descargar operaciones de solo lectura a las bases de datos en espera, que pueden actuar como bases de datos de informes con datos actualizados. Este enfoque reduce la carga y la sobrecarga en la base de datos principal de lectura y escritura.

Configuración de copias de seguridad y alta disponibilidad

Las réplicas de lectura se pueden configurar en varias zonas que proporcionan alta disponibilidad. Si bien proporcionan un RTO y un RPO bajos, no protegen contra ciertas interrupciones, como la corrupción de datos lógicos, como las eliminaciones accidentales de tablas o las actualizaciones de datos incorrectas. Por lo tanto, se deben realizar copias de seguridad periódicas además de la configuración de HA. Consulta la documentación de la arquitectura de disponibilidad estándar para obtener más detalles.

En la figura 1, se muestra una configuración de HA recomendada con dos bases de datos en espera de réplica de lectura en dos zonas de disponibilidad diferentes.

AlloyDB Omni con opciones de copias de seguridad y alta disponibilidad

Figura 1. AlloyDB Omni con copias de seguridad y opciones de alta disponibilidad

Para proteger contra la pérdida de datos si falla la instancia principal, es necesario configurar la replicación en modo síncrono. Si bien este método proporciona una protección de datos sólida, puede afectar el rendimiento de la base de datos principal, ya que todas las confirmaciones deben escribirse en la base de datos principal y en todas las bases de datos en espera sincronizadas. Una conexión de red de baja latencia entre estas instancias de base de datos es fundamental para esta configuración.

Implementaciones de HA de Kubernetes

Para las implementaciones de Kubernetes, si usas algunos cambios y adiciones de atributos básicos en tu archivo de implementación de AlloyDB Omni, puedes agregar réplicas de lectura o en espera de conmutación por error para permitir la falla de la base de datos principal. Se puede configurar una réplica de solo lectura y en espera de conmutación por error, y el operador se encarga de aprovisionar y publicar el servicio. El operador también automatiza muchos de los procesos de HA, como la reconstrucción de bases de datos en espera después de una conmutación por error y el uso de los mecanismos de reparación integrados en el motor de Kubernetes de AlloyDB Omni.

En una implementación de Kubernetes, la disponibilidad de la infraestructura y las aplicaciones se beneficia de las funciones integradas de Kubernetes que se encargan de las fallas de nodos y pods, incluidas las siguientes:

Además de la protección integrada, el operador expone los siguientes parámetros para influir en la detección de una base de datos principal o en espera con fallas:

  • healthcheckPeriodSeconds: Es el tiempo entre las verificaciones de estado. El valor predeterminado es 30 segundos.
  • autoFailoverTriggerThreshold: Es la cantidad de verificaciones de estado fallidas consecutivas antes de iniciar la conmutación por error. El valor predeterminado es 3.

Para obtener más información, consulta Administra la alta disponibilidad en Kubernetes.

Implementación

Cuando elijas una arquitectura de referencia de disponibilidad, ten en cuenta los siguientes beneficios, limitaciones y alternativas.

Beneficios

  • Protege de las fallas de instancias.
  • Protege de las fallas del servidor.
  • Protege de las fallas de la zona.
  • El RTO se reduce drásticamente de la disponibilidad estándar.

Limitaciones

  • No hay protección adicional para desastres regionales.
  • Posible impacto en el rendimiento de la base de datos principal debido a la replicación síncrona.
  • Configurar la transmisión de WAL de PostgreSQL en modo síncrono no genera pérdida de datos (RPO=0) durante el funcionamiento normal o las conmutaciones por error típicas. Sin embargo, este enfoque no protege contra la pérdida de datos en situaciones específicas de doble falla, como cuando se pierden todas las instancias en espera o no se puede acceder a ellas desde la base de datos principal, y esto se sigue inmediatamente de un reinicio principal.

Alternativas

¿Qué sigue?