Protege tus datos mediante la replicación zonal

Selecciona una versión de la documentación:

En esta página se describe la arquitectura de referencia de alta disponibilidad mejorada de AlloyDB Omni, que proporciona alta disponibilidad mediante el despliegue de una o varias réplicas de la base de datos en la misma región para protegerse frente a fallos a nivel de nodo o de zona.

Casos prácticos

Esta arquitectura de referencia de disponibilidad es adecuada para los siguientes casos prácticos:

  • Aplicaciones esenciales para el negocio que requieren un RTO y un RPO más bajos.
  • Quieres implementar una réplica en otra zona o nodo que proporcione alta disponibilidad a tus bases de datos y las proteja frente a fallos de instancias, servidores y zonas.
  • Quieres protegerte frente a errores de los usuarios y a la corrupción de datos (mediante copias de seguridad).

Cómo funciona la arquitectura de referencia

La disponibilidad mejorada se suma a la disponibilidad estándar añadiendo instancias de réplica de lectura en 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 que se transmitan los cambios transaccionales a la réplica.

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

Estos son algunos conceptos importantes sobre la alta disponibilidad:

  • La conmutación por error es el procedimiento que se lleva a cabo durante una interrupción no planificada en la que la instancia principal falla o deja de estar disponible, y se activa la réplica de espera para asumir el modo principal (lectura y escritura). Este proceso se denomina promoción. Normalmente, en estos casos, cuando el servidor o la base de datos principales vuelven a estar online, la base de datos debe reconstruirse y, después, actuar como reserva. Para ofrecer un tiempo de actividad elevado, se han implementado mecanismos para automatizar las conmutaciones por error.
  • Un cambio, también conocido como inversió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 de reserva, de forma que la principal se convierta en la de reserva y la de reserva se convierta en la principal. Los cambios suelen producirse de forma controlada y gradual, y pueden iniciarse por diversos motivos, como permitir el tiempo de inactividad y la aplicación de parches de la antigua base de datos principal. Los cambios a otro servidor deben permitir volver al servidor original sin necesidad de volver a crear una instancia del nuevo servidor de reserva ni de otros aspectos de la configuración de la réplica.

Opciones de alta disponibilidad

En las implementaciones que no son de Kubernetes, usa Patroni y HAProxy. Para obtener más información, consulta el artículo sobre la arquitectura de alta disponibilidad de AlloyDB Omni para PostgreSQL.

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

Te recomendamos que tengas al menos dos bases de datos de reserva para que la pérdida de una de ellas no afecte a la alta disponibilidad del clúster. En ese modo, tienes al menos un par de alta disponibilidad 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 Planificar la instalación de AlloyDB Omni en una VM.

Balanceadores de carga

Otro mecanismo importante que facilita los procedimientos de conmutación y de conmutación por error es la presencia de un balanceador de carga.

En las implementaciones que no son de Kubernetes, el software HAProxy proporciona balanceo de carga. HAProxy ofrece balanceo de carga distribuyendo el tráfico de red entre varios servidores. HAProxy también mantiene el estado de salud de los servidores backend a los que se conecta realizando comprobaciones de salud. Si un servidor no supera una comprobación del estado, HAProxy deja de enviarle tráfico hasta que vuelva a superar las comprobaciones del estado.

Alta disponibilidad

Las bases de datos de réplica de lectura implementadas en una región ofrecen alta disponibilidad si falla la base de datos principal. Cuando se produce un error en la base de datos principal, la base de datos de reserva se convierte en la principal y la aplicación continúa con poco o ningún tiempo de inactividad.

Por lo general, es recomendable realizar comprobaciones periódicas anuales o semestrales en forma de cambios para asegurarse de que todas las aplicaciones que dependen de estas bases de datos puedan seguir conectándose y respondiendo en un plazo adecuado.

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

Otra ventaja de tener réplicas de lectura es la posibilidad de derivar las operaciones de solo lectura a las bases de datos de reserva, que pueden actuar como bases de datos de informes con datos actualizados. Este enfoque reduce la carga y la sobrecarga de la instancia 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 proporcionen alta disponibilidad. Aunque proporcionan un tiempo de recuperación y un punto de recuperación bajos, no protegen frente a determinadas interrupciones, como la corrupción lógica de datos (por ejemplo, la eliminación accidental de tablas o las actualizaciones de datos incorrectas). Por lo tanto, deben hacerse copias de seguridad periódicas además de la configuración de alta disponibilidad. Para obtener más información, consulta la documentación sobre la arquitectura de disponibilidad estándar.

En la figura 1 se muestra una configuración de alta disponibilidad 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

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

Para protegerte frente a la pérdida de datos si falla la instancia principal, es necesario configurar la replicación en modo síncrono. Aunque este método proporciona una protección de datos sólida, puede afectar al 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 de espera sincronizadas. Para esta configuración, es fundamental que haya una conexión de red de baja latencia entre estas instancias de base de datos.

Despliegues de alta disponibilidad que no son de Kubernetes

El despliegue independiente que no es de Kubernetes es una configuración manual que requiere herramientas de terceros, lo que hace que sea más complejo de configurar y mantener que el despliegue de Kubernetes.

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

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

Para obtener más información, consulta el artículo sobre la arquitectura de alta disponibilidad de AlloyDB Omni para PostgreSQL.

Implementación

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

Ventajas

  • Protege frente a fallos de instancias.
  • Protege frente a fallos del servidor.
  • Protege frente a fallos de zona.
  • El tiempo de recuperación tras un fallo se reduce drásticamente en comparación con la disponibilidad estándar.

Limitaciones

  • No hay protección adicional en caso de desastres regionales.
  • Posible impacto en el rendimiento de la instancia principal debido a la replicación síncrona.
  • Configurar 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 fallo, como cuando se pierden todas las instancias de espera o no se puede acceder a ellas desde la instancia principal, y a continuación se reinicia la instancia principal.

Alternativas

Siguientes pasos