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 contra fallas a nivel de nodos o zonas.

Casos de uso

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

  • Aplicaciones fundamentales para la empresa que requieren un RTO y un RPO más bajos
  • Deseas implementar una réplica en otra zona o nodo que proporcione alta disponibilidad para tus bases de datos y proteja contra fallas zonales, de instancias y de servidores.
  • Deseas 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, ya que agrega 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), ya que permite transmitir los 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 funcionan como réplicas de lectura y operan en modo de solo lectura.

A continuación, se incluyen conceptos importantes de la HA:

  • La conmutación por error es el procedimiento que se realiza 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 una base de datos en espera. Para proporcionar un tiempo de actividad alto, existen 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 producen de forma controlada y gradual, y se pueden iniciar por varios motivos, por ejemplo, para permitir el tiempo de inactividad y la aplicación de parches en la base de datos principal anterior. Los cambios graduales deben permitir un cambio posterior sin necesidad de volver a crear una instancia del nuevo servidor en espera ni otros aspectos de la configuración de replicación.

Opciones de alta disponibilidad

Para admitir la HA, puedes implementar AlloyDB Omni de las siguientes maneras:

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 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 conmutación y conmutación por error sean más fluidos es la presencia de un balanceador de cargas. Para las implementaciones que no son de Kubernetes, el software HAProxy proporciona balanceo de cargas. HAProxy ofrece balanceo de cargas distribuyendo el tráfico de red en 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 aprobar las verificaciones de estado.

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 en 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 a la principal y la aplicación continúa con poca o ninguna interrupción.

En general, es una buena práctica realizar verificaciones periódicas anuales o semestrales en forma de conmutaciones 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 transferir 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 el nodo 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 lógica de los datos, como la eliminación accidental de tablas o las actualizaciones incorrectas de los datos. Por lo tanto, además de la configuración de HA, se deben realizar copias de seguridad periódicas. Consulta la documentación sobre la arquitectura de disponibilidad estándar para obtener más información.

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

AlloyDB Omni con opciones de copias de seguridad y alta disponibilidad

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

Para protegerte contra la pérdida de datos en caso de que falle la instancia principal, es necesario configurar la replicación en modo síncrono. Si bien este método proporciona una sólida protección de los datos, 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

En el caso de las implementaciones de Kubernetes, puedes agregar réplicas de lectura o en espera de conmutación por error para permitir la falla de la base de datos principal. Para ello, usa algunos cambios y adiciones básicos de atributos en tu archivo de implementación de AlloyDB Omni. Se puede configurar una réplica de solo lectura y en espera para la conmutación por error, y el operador se encarga del aprovisionamiento y la publicación del servicio. El operador también automatiza muchos de los procesos de HA, como la recompilació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 instancia principal o en espera con errores:

  • 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.

Implementaciones de HA que no son de Kubernetes

La implementación independiente que no es de Kubernetes es una configuración manual que requiere herramientas de terceros, que son más complejas de configurar y mantener que la implementación de Kubernetes.

Cuando usas una implementación que no es de Kubernetes, hay algunos parámetros que afectan la forma en que se detecta una conmutación por error y la rapidez con la que se produce después de que el servidor principal deja de estar disponible. A continuación, se incluye un breve resumen de esos parámetros:

  • Ttl: Es el tiempo máximo que se tarda en adquirir un bloqueo para la base de datos principal antes de iniciar una conmutación por error. La configuración predeterminada es 30 segundos.
  • Loop_wait: Es la cantidad de tiempo que se debe esperar antes de volver a verificar. El valor predeterminado es 10 segundos.
  • Retry_timeout: Es el tiempo de espera antes de degradar la instancia principal debido a una falla de red. El tiempo predeterminado es 10 segundos.

Para obtener más información, consulta Arquitectura de alta disponibilidad para AlloyDB Omni para PostgreSQL.

Implementación

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

Beneficios

  • Protege contra fallas de instancias.
  • Protege contra fallas del servidor.
  • Protege contra fallas zonales.
  • El RTO se redujo drásticamente en comparación con la disponibilidad estándar.

Limitaciones

  • No hay protección adicional para desastres regionales.
  • Posible impacto en el rendimiento de la instancia principal debido a la replicación síncrona.
  • La configuración de la transmisión de WAL de PostgreSQL en modo síncrono ofrece cero 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 dejan de ser accesibles desde la instancia principal, y esto es seguido inmediatamente por un reinicio de la instancia principal.

Alternativas

¿Qué sigue?