Voy a agregar información actualizada y referencias a la excelente respuesta de @ max-malysh arriba.
En resumen, si hace algo en el maestro, debe replicarse en el esclavo. Postgres utiliza registros WAL para esto, que se envían después de cada acción registrada en el maestro al esclavo. El esclavo ejecuta la acción y los dos están nuevamente sincronizados. En uno de varios escenarios, puede estar en conflicto con el esclavo con lo que viene del maestro en una acción WAL. En la mayoría de ellos, está ocurriendo una transacción en el esclavo que entra en conflicto con lo que la acción WAL quiere cambiar. En ese caso, tiene dos opciones:
- Retrasar la aplicación de la acción WAL por un momento, permitiendo que el esclavo finalice su transacción conflictiva, luego aplique la acción.
- Cancele la consulta conflictiva en el esclavo.
Nos preocupa el # 1 y dos valores:
max_standby_archive_delay
- este es el retraso utilizado después de una larga desconexión entre el maestro y el esclavo, cuando los datos se leen desde un archivo WAL, que no son datos actuales.
max_standby_streaming_delay
- retraso utilizado para cancelar consultas cuando se reciben entradas WAL a través de la replicación de transmisión.
En general, si su servidor está diseñado para replicación de alta disponibilidad, desea mantener estos números cortos. La configuración predeterminada de 30000
(milisegundos si no se dan unidades) es suficiente para esto. Sin embargo, si desea configurar algo como una réplica de archivo, informe o lectura que pueda tener consultas de larga duración, entonces querrá configurar esto en algo más alto para evitar consultas canceladas. La 900s
configuración recomendada arriba parece un buen punto de partida. No estoy de acuerdo con los documentos oficiales sobre establecer un valor infinito -1
como una buena idea, que podría enmascarar algunos códigos defectuosos y causar muchos problemas.
La única advertencia sobre las consultas de larga duración y el establecimiento de estos valores más altos es que otras consultas que se ejecutan en el esclavo en paralelo con la de larga duración que está causando que la acción WAL se retrase verán datos antiguos hasta que se complete la consulta larga. Los desarrolladores deberán comprender esto y serializar las consultas que no deberían ejecutarse simultáneamente.
Para la explicación completa de cómo max_standby_archive_delay
y max_standby_streaming_delay
trabajar y por qué, vaya aquí .