Replicación y consistencia de datos

Replicar es mantener copias vivas de tus datos en otro lugar. Toda replicación responde dos preguntas: ¿cuándo confirma el primario que una escritura quedó guardada?, y ¿qué ve quien lee de la copia? De esas respuestas salen tu RPO, la latencia de cada escritura y los errores raros que aparecen el día del desastre.

Síncrona o asíncrona

¿Por qué no replicar todo de forma síncrona entre regiones? Por la física. La luz en fibra óptica recorre unos 200 000 km por segundo. Con una región a 1 000 km, el viaje de ida y vuelta toma al menos 10 ms antes de sumar equipos de red, y cada escritura lo paga. Una transacción con diez escrituras seguidas ya suma 100 ms solo en esperar. Además, una falla en la región remota frena las escrituras de la principal. Por eso la replicación síncrona vive dentro de una región, entre zonas cercanas, y entre regiones domina la asíncrona. Repasa las distancias en comunicación entre zonas y regiones.

Consistencia fuerte o eventual

Con consistencia fuerte, toda lectura ve la última escritura confirmada. Con consistencia eventual, las copias terminan iguales, pero durante un rato una lectura puede devolver un valor viejo.

El problema clásico es leer lo que acabas de escribir (read-after-write). Un usuario cambia su dirección, recarga la página y ve la dirección vieja, porque la lectura fue a una réplica atrasada. Hay tres salidas: leer del primario justo después de escribir, mandar a cada usuario siempre a la región donde escribe, o usar un modo de lectura fuerte donde exista. Dentro de una región, S3 ya da consistencia fuerte de lectura después de escritura, y DynamoDB ofrece lecturas fuertes con ConsistentRead. Entre regiones, casi todo es eventual salvo que elijas lo contrario.

Las transacciones en vuelo

A las 14:39:59 el primario confirma el pedido 1001 y el cliente recibe su correo. El retraso de replicación es de 2 segundos. A las 14:40:00 cae la región. El secundario se promueve sin el pedido 1001. Pueden pasar dos cosas:

• Se pierde: el cliente tiene un correo de un pedido que no existe en la base nueva.
• Hay que reconciliarlo: cuando la región vieja vuelve, aparece un pedido que la base nueva nunca vio. Si la base nueva ya usó el número 1001 para otro cliente, tienes dos pedidos con el mismo número.

Por eso conviene usar identificadores que no dependan de un contador del primario (por ejemplo, UUID) y guardar en otro lugar la evidencia para reconciliar: el proveedor de pagos, una cola de eventos, los correos enviados. Aurora ayuda en este punto: tras un failover de Aurora Global Database intenta tomar un snapshot del volumen viejo en el momento de la falla, llamado rds:unplanned-global-failover-…, para que recuperes lo que no alcanzó a cruzar.

Otro concepto clave es el punto consistente. Una copia sirve si cada transacción está completa o ausente, nunca a medias. Las bases de datos lo garantizan al promover una réplica o restaurar un snapshot. Varios discos copiados por separado no: si una aplicación escribe en dos volúmenes, sus snapshots deben tomarse juntos. Y con DynamoDB global tables en modo eventual, una transacción solo es atómica en la región donde se ejecutó; otra región puede verla a medias mientras se replica.

Las opciones de AWS

• 

  RDS Multi-AZ

  Copia síncrona en otra zona de la misma región y failover automático. Protege de la caída de una instancia o una zona, no de una región. Detalles en RDS y Aurora.
• 

  Réplica de lectura de RDS en otra región

  Asíncrona. Al promoverla se vuelve una base independiente y la replicación se corta: no hay vuelta atrás automática.
• 

  Aurora Global Database

  Replica a nivel de almacenamiento, con retraso típico de menos de 1 segundo. Un solo clúster primario escribe; los secundarios leen.
• 

  DynamoDB global tables

  Réplicas en varias regiones que aceptan lecturas y escrituras. Eliges el modo de consistencia al crear la tabla y no se puede cambiar después.
• 

  Replicación de S3

  Asíncrona entre buckets, en otra región (CRR) o la misma (SRR). Requiere versionado. Con Replication Time Control tienes un tiempo comprometido y métricas.
• 

  ElastiCache Global Datastore

  Para Valkey y Redis OSS en clústeres basados en nodos. Un clúster primario escribe y los secundarios, en otras regiones, solo leen. Puedes promover un secundario.

Aurora Global Database tiene dos formas de cambiar de región. El switchover (antes llamado «managed planned failover») espera a que el secundario esté al día y luego cambia los roles: RPO cero, para mantenimiento o simulacros. El failover no espera y puede perder lo que no se replicó: es para desastres, y en la CLI exige el parámetro --allow-data-loss. Con Aurora PostgreSQL puedes poner un tope al RPO con el parámetro rds.global_db_rpo: si todos los secundarios van más atrasados que ese valor, Aurora frena los commits en el primario hasta que uno se ponga al día. Cambias disponibilidad por un RPO acotado.

DynamoDB global tables tiene dos modos. En consistencia eventual multirregión (MREC, el modo por defecto), cada región escribe localmente, los cambios se propagan normalmente en un segundo o menos y, si dos regiones modifican el mismo ítem a la vez, gana la escritura con la marca de tiempo más reciente (last writer wins). En consistencia fuerte multirregión (MRSC), cada escritura se replica de forma síncrona a al menos otra región antes de confirmarse: RPO cero, a cambio de más latencia. MRSC exige exactamente tres regiones (tres réplicas, o dos réplicas y un testigo), no admite transacciones, TTL ni índices secundarios locales, y si dos regiones modifican el mismo ítem a la vez una recibe ReplicatedWriteConflictException y debe reintentar.

Para llevar cambios a un sistema externo o a otro motor (por ejemplo, de Aurora a un almacén analítico), AWS DMS ofrece replicación continua con captura de cambios (CDC). También es asíncrona. Lo verás en migrar bases de datos.

Comparación rápida

Criterio	RDS Multi-AZ	Réplica entre regiones	Aurora Global Database	Global tables MREC	Global tables MRSC
Alcance	Una región, varias zonas	Varias regiones	Varias regiones	Varias regiones	Exactamente tres regiones
Replicación	Síncrona	Asíncrona	Asíncrona, por almacenamiento	Asíncrona	Síncrona hacia al menos otra región
RPO si cae la región	No cubre ese caso	El ReplicaLag	Segundos (cero con switchover planeado)	Normalmente pocos segundos	Cero
Dónde se escribe	Solo el primario	Solo el primario	Solo el clúster primario	En todas las regiones	En todas las regiones
Lectura en la copia	No en el standby clásico	Eventual	Eventual	Eventual entre regiones	Fuerte
Cambio de primario	Automático	Manual: promover	Switchover o failover administrado	No hay primario: mueves el tráfico	No hay primario: mueves el tráfico