Réplicas de lectura y lag de replicación: cómo se ven las lecturas obsoletas y cómo acotarlas

Qué es

En la replicación por streaming de PostgreSQL, el primario envía registros del write-ahead log a los standbys, que los reproducen; un hot standby también atiende consultas de solo lectura. La replicación es asíncrona por defecto: un commit se devuelve antes de que ningún standby tenga los datos. La documentación (citada) describe los niveles de synchronous_commit que hacen que un commit espere a que un standby haya escrito, vaciado (flush) o, con remote_apply, reproducido la transacción de modo que quede visible para las consultas allí, lo que según la documentación permite balanceo de carga con consistencia causal en casos simples; los standbys implicados se nombran en synchronous_standby_names.

La reproducción y las consultas compiten entre sí. La documentación del hot standby (citada) explica que la aplicación del WAL puede entrar en conflicto con consultas en curso (por ejemplo, cuando una fila que necesita una consulta ya se limpió en el primario); pasado max_standby_streaming_delay se cancela la consulta en conflicto, y hot_standby_feedback impide que el VACUUM del primario elimine filas que un standby todavía necesita, a costa de hinchazón (bloat) en el primario. La monitorización usa pg_stat_replication en el primario y las funciones de posición de reproducción (citadas), como pg_last_wal_replay_lsn(), en el standby.

Por qué importa

El fallo típico: una persona usuaria envía un formulario (escritura en el primario), la página siguiente lista elementos (lectura desde la réplica) y el elemento nuevo falta; un reintento lo muestra. Los trabajos en segundo plano que leen desde una réplica actúan sobre un estado obsoleto. No son casos límite raros, sino el comportamiento normal bajo lag.

Cómo aplicarlo

• Clasificar las lecturas: las lecturas posteriores a una escritura dentro del mismo flujo de la persona usuaria van al primario, o quedan fijadas a él durante un breve periodo tras cualquier escritura de esa sesión; los paneles y la búsqueda pueden usar réplicas libremente.
• Para una comprobación estricta de lectura de las propias escrituras, registrar la posición de commit del primario y dejar que la lectura en la réplica continúe solo cuando su posición de reproducción la haya alcanzado.
• Dar a las réplicas analíticas un retraso de standby grande para que las consultas largas no se cancelen; mantener el retraso corto en las réplicas que sirven lecturas sensibles a la latencia.
• Alertar sobre el lag en bytes y en segundos, y sobre el número de cancelaciones de consulta en cada standby.
• Usar modos síncronos solo para los standbys y las cargas de trabajo donde se acepten la latencia adicional del commit y el riesgo de commits estancados cuando un standby está caído.

Trampas

Un proxy que enruta sentencias por tipo (cada SELECT a una réplica) puede enviar las propias lecturas de una transacción lejos del primario, a menos que rastree la transacción. Una réplica promovida durante un failover puede ir por detrás del antiguo primario, de modo que los commits recientes pueden perderse con replicación asíncrona. El lag bajo carga de escritura intensa crece precisamente cuando las lecturas son más intensas.