Protege tus datos con la replicación zonal y regional

Selecciona una versión de la documentación:

En esta página, se describe la arquitectura de referencia de disponibilidad premium de AlloyDB Omni, que incluye la protección de datos mediante la replicación zonal en una región (alta disponibilidad) y agrega protección de recuperación ante desastres (DR) mediante la transmisión asíncrona en grandes límites geográficos.

Esta arquitectura de referencia es más adecuada para los siguientes casos de uso:

  • Necesitas protección regional además de la protección zonal para tus aplicaciones de misión crítica.

Esta arquitectura de referencia de disponibilidad incorpora réplicas de lectura dentro de la región para HA y en todas las regiones para DR. Esta implementación multirregional protege contra interrupciones significativas, incluidas las fallas de energía generalizadas y los desastres naturales a gran escala.

Consideraciones sobre la arquitectura de referencia de disponibilidad

Cuando evalúes esta arquitectura de referencia de disponibilidad, ten en cuenta los siguientes factores:

  • Latencia y ancho de banda de la red dentro de la región y entre regiones
  • Ubicación geográfica de las bases de datos y los servidores de aplicaciones
  • Estrategia para descargar cargas de trabajo de solo lectura en réplicas
  • Implementa la alta disponibilidad en la región de DR remota

Es posible que se requiera el balanceo de cargas de solo lectura, en especial si usas servidores de aplicaciones regionales, de modo que las solicitudes se reenvíen a la base de datos más cercana para obtener la respuesta más rápida. Para obtener más información, consulta Solicita el enrutamiento a un balanceador de cargas de aplicaciones clásico multirregional.

Es posible que se requiera supervisación adicional para la replicación entre regiones para garantizar que la demora de la replicación no comience a aumentar debido a la carga de transacciones o la capacidad de la red.

Para asegurarte de que tu DR sea exitoso, realiza pruebas exhaustivas de DR. Es importante probar la funcionalidad y el rendimiento de la aplicación si hay conexiones de red de alta latencia entre los servidores de aplicaciones y la base de datos.

Arquitecturas de HA en la región y DR entre regiones

En la Figura 1, se muestra una configuración sugerida de HA y DR con tres bases de datos de reserva de réplica de lectura en tres zonas de disponibilidad y dos regiones.

AlloyDB Omni con opciones de copias de seguridad y alta disponibilidad entre regiones

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

Como se ilustra en la Figura 1, la replicación de transmisión síncrona a réplicas locales (dentro de la misma región) proporciona alta disponibilidad, mientras que la replicación de transmisión asíncrona a una réplica remota separada geográficamente proporciona protección de recuperación ante desastres regional. En toda la configuración, solo la instancia principal puede realizar operaciones de lectura y escritura, mientras que las otras réplicas pueden atender consultas de lectura.

Configura la replicación de la instancia principal a las réplicas en la región en modo síncrono, mientras que la replicación a las réplicas entre regiones se configurará en modo asíncrono para evitar que la latencia afecte el rendimiento de escritura principal. En caso de una falla regional, esta configuración podría generar un RPO distinto de cero. Sin embargo, esta configuración permite un RTO más rápido en caso de falla. Esto se debe a que la base de datos principal no necesita esperar la confirmación de las bases de datos de reserva remotas antes de confirmar las transacciones.

Es posible que las copias de seguridad adicionales entre regiones tomen copias de seguridad de las bases de datos de réplica de lectura y, por lo tanto, agreguen redundancia a las copias de seguridad tomadas de la base de datos principal.

Copias de seguridad de réplicas de lectura

Cuando usas implementaciones de Kubernetes, la implementación secundaria en la región alternativa se configura automáticamente con copias de seguridad adicionales.

Ten en cuenta lo siguiente:

  • Si tu copia de seguridad remota puede ser susceptible a fallas regionales, debes iniciar copias de seguridad adicionales en las regiones alternativas.
  • Si necesitas redundancia de copia de seguridad, debes tomar copias de seguridad de réplicas de lectura regionales.

Ubicación de la réplica de lectura para admitir la disponibilidad multizonal

El operador de Kubernetes de AlloyDB Omni controla automáticamente la ubicación de los nodos en las zonas y a qué nodos se deben implementar los pods. Algunas opciones de configuración que afectan la ubicación, como la afinidad y la tolerancia de los pods, están disponibles en la configuración de la base de datos que se usa para implementar con el operador de AlloyDB Omni.

Migración de una arquitectura solo de HA a una de HA y DR

Para las implementaciones de Kubernetes, debes compilar una nueva implementación regional de Kubernetes, llamada clúster de base de datos secundario, y habilitar la replicación entre centros de datos.

Implementación

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

Beneficios

  • Protege contra fallas zonales y de instancias.
  • Protege contra fallas regionales.
  • El RTO se reduce cuando la base de datos experimenta una falla regional.

Limitaciones

  • Puedes reducir el RPO para la recuperación regional con la replicación síncrona, pero este enfoque causa latencia adicional para el rendimiento de las transacciones. Para la replicación de DR y de regiones remotas, te recomendamos que uses solo la replicación así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 falla, como cuando se pierden todas las instancias de reserva o se vuelven inaccesibles desde la instancia principal, y esto es seguido de inmediato por un reinicio principal.

Opciones de protección de datos

¿Qué sigue?