Síncrono vs. Asíncrono
La replicación asíncrona favorece el rendimiento y la baja latencia de confirmación; la replicación síncrona reduce el RPO a costa de la latencia del standby y la sensibilidad a la disponibilidad.
Receta
Asíncrono por defecto en el primario; añadir un standby síncrono para datos de nivel 0.
-- Asíncrono (por defecto): las confirmaciones se devuelven cuando el WAL local se ha volcado
ALTER SYSTEM SET synchronous_commit = 'on';
-- Síncrono a un standby nombrado
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (standby1)';
SELECT pg_reload_conf();-- En el standby: establecer application_name para que coincida con synchronous_standby_names
ALTER SYSTEM SET cluster_name = 'standby1';
SELECT pg_reload_conf();Cuándo usar esto: Necesitas cero o casi cero pérdida de transacciones confirmadas en caso de fallo del primario y puedes aceptar latencia adicional de confirmación.
Ejemplo de Trabajo
Medir el impacto síncrono y verificar el estado del socio:
-- Primario: inspeccionar socios síncronos
SELECT application_name, sync_state, sync_priority, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
-- Compromiso de durabilidad a nivel de sesión (ventana de carga masiva)
SET synchronous_commit = 'off';
COPY staging.events FROM '/data/events.csv' CSV;
RESET synchronous_commit;# Evaluar la latencia de confirmación asíncrona vs. síncrona (pgbench)
pgbench -h primary.db.internal -U app -c 4 -j 4 -T 30 -S appdb
pgbench -h primary.db.internal -U app -c 4 -j 4 -T 30 -S appdb \
--sync-method=strictLo que esto demuestra:
synchronous_standby_nameselige qué standbys cuentan para el quórum.sync_state = 'sync'confirma que el socio participa en las confirmaciones síncronas.synchronous_commit = offacelera las cargas masivas pero amplía el RPO solo para esa sesión.
Profundización
Cómo Funciona
- Asíncrono: El primario devuelve
COMMITdespués de volcar el WAL local (segúnsynchronous_commit). El standby se pone al día más tarde. - Síncrono: El primario espera hasta que los standbys requeridos vuelquen (y opcionalmente apliquen) el WAL antes de que
COMMITse devuelva. - Niveles de
synchronous_commit:off,local,remote_write,remote_apply,on(se mapea al quórum desynchronous_standby_names). FIRST n (...)significa que cualquier n standby listado satisface el quórum;ANY n (...)es un estilo de quórum alternativo en PostgreSQL 18.
Instantánea de RPO y RTO
| Modo | RPO Típico en fallo del primario | Latencia de confirmación | Notas de Failover |
|---|---|---|---|
| Asíncrono | Últimos segundos de WAL confirmados | Más bajo | Promover standby; puede perder confirmaciones recientes |
| Síncrono (1 socio) | Cero pérdida de confirmaciones si el socio está sano | + RTT al standby | El failover si el socio está muerto bloquea las confirmaciones a menos que relajes la sincronización |
remote_apply | Cero pérdida; las lecturas en el standby ven la confirmación | Más alto | La consistencia más fuerte, confirmaciones más lentas |
Nota sobre Patroni 3.x
Patroni establece synchronous_mode y gestiona synchronous_standby_names durante el failover. Prueba la configuración de sincronización de Patroni en staging antes de producción; un standby síncrono perdido puede detener las escrituras.
Errores Comunes
- Dos standbys síncronos sin presupuesto de latencia - La confirmación espera a la réplica geográfica más lenta. Solución: Como máximo un socio síncrono a menos que modeles el RTT de la WAN.
- Socio síncrono caído - Las escrituras se cuelgan si no se puede cumplir el quórum. Solución: Política de failover de Patroni o reducir temporalmente
synchronous_standby_names. synchronous_commit = offglobalmente - Rápido pero el RPO se amplía para todas las sesiones. Solución: Limitar a ventanas de mantenimiento o roles de lote únicamente.application_namemal nombrado - El standby nunca se convierte en socio síncrono. Solución: Coincidir nombres enpg_stat_replication.application_name.- Confundir sincronización con replicación lógica - Protocolo y garantías diferentes. Solución: La sincronización física es quórum de WAL; la lógica es flujo de cambios.
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Asíncrono + backups base frecuentes | DR entre regiones con RPO flexible | El libro mayor financiero necesita cero pérdidas |
| Replicación lógica | Actualización de versión, tablas selectivas | Necesitas quórum físico síncrono |
synchronous_commit = remote_write | Equilibrar latencia vs durabilidad | Requiere visibilidad de replay del standby antes de la confirmación |
Preguntas Frecuentes
¿Cuántos standbys síncronos debería ejecutar?
Un socio síncrono local es el patrón de producción común. Más socios aumentan la latencia y los modos de fallo.
¿La replicación síncrona bloquea las lecturas en el primario?
No. Solo las transacciones que se confirman esperan el acuse de recibo del standby.
¿Qué sucede si el standby síncrono muere?
Las confirmaciones se bloquean hasta que se restaura el quórum o cambias synchronous_standby_names. Patroni puede degradar el modo síncrono automáticamente.
¿Es `remote_apply` siempre mejor?
Espera el replay del standby, no solo el volcado. Úsalo solo cuando las aplicaciones lean del standby inmediatamente después de la confirmación.
¿Puede PgBouncer afectar el comportamiento síncrono?
PgBouncer agrupa conexiones pero no cambia las semánticas síncronas de PostgreSQL. La configuración de sesión como synchronous_commit se aplica por conexión backend.
Relacionados
- Conceptos Básicos de Replicación en Streaming - configuración
- Replication Slots - retención de WAL
- Patroni y etcd/Consul - automatización del modo síncrono
- Conceptos Básicos de DR - definiciones de RPO/RTO
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.