Configuración multirregión con Amazon Aurora Global Database - Diseño de DR y lecturas globales

Logra un RPO de menos de 1 segundo mediante la replicación física en la capa de almacenamiento. Presenta los procedimientos de conmutación por error planificada y no planificada, y cómo aprovechar Write Forwarding para las lecturas globales.

Cómo funciona Global Database

Aurora Global Database es una función que replica los datos de la región principal en regiones secundarias, y se pueden tener hasta 10 regiones secundarias. Mientras que las réplicas de lectura entre regiones habituales utilizan la replicación lógica basada en binlog, Global Database utiliza la replicación física en la capa de almacenamiento. Gracias a ello, el retardo de replicación se mantiene normalmente por debajo de 1 segundo y el impacto en el rendimiento de la instancia principal se mantiene reducido. Está disponible tanto para la edición compatible con MySQL como para la compatible con PostgreSQL, y requiere una clase de instancia db.r6g.large o superior.

Diseño de DR y conmutación por error

La transición (switchover), que realiza un cambio de región planificado (antes llamada managed planned failover), se utiliza en el mantenimiento o la migración de región y promueve una región secundaria a principal sin perder datos. Como detiene las escrituras en la principal y espera a que se complete la replicación antes de cambiar, no hay pérdida de datos. La conmutación por error (failover), que se utiliza cuando falla la región principal, se completa normalmente en un plazo de 1 minuto. Puede producirse una pérdida de datos equivalente al retardo de replicación, pero el RPO es normalmente de menos de 1 segundo. Si la aplicación se conecta al punto de enlace de escritura de Aurora Global Database, después de una transición o una conmutación por error este punto de enlace apunta a la principal de ese momento. Si combina las comprobaciones de estado de Route 53 con el direccionamiento de conmutación por error, puede cambiar el destino de conexión automáticamente mediante DNS.

Aprovechamiento de las lecturas globales

Las réplicas de lectura de las regiones secundarias pueden procesar consultas de lectura y ofrecen lecturas de baja latencia a usuarios distribuidos por todo el mundo. Si configura la región de Tokio como principal y la región de Virginia como secundaria, los usuarios de Estados Unidos leen desde la réplica de lectura de Virginia y los usuarios de Japón leen desde la principal de Tokio. Como solo la principal procesa las escrituras, las escrituras de los usuarios alejados de la región principal tardan un tiempo que depende de la distancia. Si habilita el reenvío de escrituras (Write Forwarding), el lado secundario envía las solicitudes de escritura a la principal, por lo que puede reducir el procesamiento que reparte las regiones en el lado de la aplicación.

Precios de Global Database

El coste adicional de Global Database se genera por la E/S de escritura de los datos replicados. La E/S de replicación en la región secundaria cuesta aproximadamente 0.20 USD por millón de solicitudes (a fecha de agosto de 2026). Los precios de las instancias y del almacenamiento en la región secundaria son los mismos que en Aurora normal. La clase de instancia de las réplicas de lectura no tiene por qué ser la misma que la de la principal, por lo que puede elegir instancias más pequeñas según la carga de lectura. Si se usa solo para DR sin utilizar réplicas de lectura, puede reducir costes manteniendo en espera la instancia mínima y escalándola verticalmente en el momento de la conmutación por error. Las tarifas de transferencia de datos entre regiones no se cobran por la replicación de Global Database.

RPO / RTO y el cambio en la práctica

En la recuperación ante desastres, cuánta pérdida de datos se puede tolerar (RPO) y con qué rapidez hay que recuperarse (RTO) son indicadores importantes. Como Aurora Global Database replica los cambios de la región principal en otras regiones mediante una infraestructura dedicada, puede mantener reducidos los datos que se pierden ante un fallo de región. Admite tanto el cambio de región planificado como la promoción de emergencia, y puede promover en poco tiempo una región secundaria a principal con escritura. Si prepara de antemano el procedimiento de cambio y lo ensaya con regularidad, puede comprobar con antelación el tiempo que tarda la recuperación.

Casos de uso y consideraciones de diseño

Aurora Global Database es una función pensada para aplicaciones con usuarios en distintas partes del mundo. Al hacer que lean desde la base de datos secundaria de cada región, puede devolver los datos con baja latencia desde un lugar cercano a los usuarios. Por otro lado, como las escrituras se concentran en la región principal, en el diseño se tiene en cuenta que las escrituras desde lugares remotos sufren latencia. Además, como la replicación entre regiones tiene un ligero retardo, se asume la posibilidad de que los datos leídos en una región secundaria estén desactualizados por un instante. El procesamiento que necesita los datos más recientes se dirige a la región principal, y las demás lecturas se reparten entre las bases de datos secundarias de cada región.

Resumen

Aurora Global Database es una función que replica los datos en varias regiones en la capa de almacenamiento y que se puede usar para recuperarse de fallos de región y para leer en regiones cercanas a los usuarios. La transición se utiliza para cambiar de región sin perder datos, y la conmutación por error se utiliza para recuperarse de un fallo de la región principal. Se puede usar en la capa de datos de aplicaciones que concentran las escrituras en una sola región y reparten las lecturas entre las regiones.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Compartir