Una réplica contiene otra copia del estado. Su utilidad depende de cómo recibe cambios, qué confirmación espera el escritor y cómo se elige un nuevo dueño después de un fallo. Tener tres servidores no define por sí solo qué datos sobreviven ni cuánto tarda en recuperarse el servicio.
La durabilidad describe qué efectos confirmados se conservan bajo un modelo de fallos. La disponibilidad describe si puede atenderse una operación. Replicar puede ayudar a ambas, pero no las vuelve equivalentes ni sustituye un respaldo restaurable.
Qué significa confirmar una escritura
El contrato comienza en el ack. Una base puede confirmar después de registrar localmente el cambio y enviarlo de forma asíncrona a otra instancia. Si el primario desaparece antes de que esa réplica lo reciba, promoverla puede perder una escritura que el cliente ya consideraba completada.
PostgreSQL permite replicación síncrona configurada para esperar confirmaciones de determinados standbys. El nivel de espera distingue recepción, persistencia o aplicación, según configuración. Esa decisión añade latencia y puede bloquear escrituras si los participantes requeridos no responden. No significa que cualquier combinación de pérdidas sea tolerable.
El contrato de consistencia también define desde dónde se lee. Una escritura durable en el primario puede no estar todavía visible en una réplica de lectura.
Copias y progreso observable
El diagrama representa replicación asíncrona. La confirmación al cliente no afirma que todos los consumidores del log hayan alcanzado la misma posición.
--- config: look: handDrawn --- flowchart TD client["Cliente"] --> writer["Primario autoritativo"] writer --> log["Registro durable local"] log --> ack["Confirmación al cliente<br/>Según contrato"] log -->|"Replicación asíncrona"| replica["Réplica<br/>Progreso medido"] replica --> read["Lectura con contrato<br/>de frescura"] log --> backup["Respaldo y archivo de log<br/>Retención independiente"]
Se observa la distancia entre posiciones y también su antigüedad. Un número pequeño de bytes pendientes no garantiza un retraso temporal pequeño si el destino dejó de aplicar. Las métricas deben distinguir transporte, persistencia y aplicación cuando el motor los expone.
Failover y autoridad de escritura
Promover una réplica implica elegir qué historia se conserva y quién puede escribir. El primario anterior puede seguir vivo tras una partición de red. Si ambos aceptan cambios independientes sobre la misma identidad, resolver el conflicto después puede violar invariantes de inventario o pagos.
La arquitectura necesita un mecanismo de elección y exclusión compatible con el motor: membresía coordinada, fencing o retirada efectiva del antiguo escritor. Cambiar DNS no detiene conexiones existentes ni demuestra que el dueño anterior quedó cercado. Clientes, pools y procesos de fondo deben reconocer la nueva autoridad.
Un timeout durante el cambio no prueba que una escritura abortó. La recuperación usa la misma identidad de operación y consulta el resultado durable, como explica Idempotencia y resultados inciertos.
Lecturas y réplicas adicionales
Una réplica puede aliviar consultas, pero no divide automáticamente la carga de una escritura autoritativa. Consultas pesadas también pueden retrasar la aplicación del log o aumentar costes, según el motor y la configuración.
Para leer después de escribir, puede usarse el escritor o una réplica que haya alcanzado una posición conocida, si el sistema ofrece esa comprobación. Esperar tiene un plazo y una política de fallback. La aplicación no debe anunciar frescura fuerte sólo porque todos los nodos están saludables.
En Sharding, cada shard necesita su propia política de réplica, failover y respaldo. Distribuir datos entre shards y mantener copias son decisiones distintas; ambas deben preservar el dueño de cada partición.
Zona, región y respaldo
| Mecanismo | Fallo que puede atender | Lo que falta comprobar |
|---|---|---|
| Réplicas entre zonas de una región | Pérdida de una instancia o zona, según diseño. | Cómputo promovible, exclusión del escritor anterior y recuperación de clientes. |
| Copia en otra región | Desastre regional o continuidad geográfica. | Retraso, pérdida posible, dependencias regionales y procedimiento de failover. |
| Respaldo con historial | Borrado lógico, corrupción o recuperación a un punto anterior. | Retención, permisos, integridad y restauración ensayada. |
Aurora distingue redundancia de almacenamiento entre zonas de una región de la replicación entre regiones de Global Database. Un switchover planificado puede esperar sincronización; un failover no planificado puede perder cambios aún no replicados. Las garantías concretas pertenecen a ese producto y configuración.
Replicar un borrado equivocado también copia el error. Un backup independiente no es útil si sus claves, permisos o procedimiento sólo existen en el entorno perdido.
RTO y RPO con supuestos
RTO es el objetivo de tiempo para recuperar el servicio; RPO es la pérdida de datos tolerada, expresada habitualmente como distancia temporal. Son objetivos que deben contrastarse con ensayos, no resultados garantizados por seleccionar una casilla Multi-AZ.
Como ejemplo hipotético, un equipo puede pedir RTO de quince minutos y RPO de treinta segundos para un catálogo. El ensayo mide detección, decisión, promoción, reconexión y comprobación funcional. Una réplica atrasada dos minutos incumple ese RPO aunque responda rápido después de promoverse.
Una venta confirmada puede requerir un contrato más estricto que el catálogo. También importan objetos, colas, secretos accesibles por los mecanismos autorizados y servicios dependientes. Recuperar sólo la base no demuestra recuperación del flujo completo.
Verificar antes del incidente
Los ensayos incluyen detener un primario, aislarlo sin apagarlo, retrasar una réplica y restaurar un backup en un entorno separado. Se comprueba que no aparecen dos escritores válidos, que los intentos inciertos pueden resolverse y que las lecturas cumplen el contrato anunciado.
Se registran versión, posición, pérdida observada, duración de cada fase y diferencias reconciliadas. La observabilidad de invariantes permite comprobar resultados además de salud de procesos. Un ejercicio incompleto se describe como tal; la recuperación depende de las fronteras realmente ensayadas.
Referencias: replicación síncrona de PostgreSQL y recuperación regional de Aurora Global Database.