Saltar al contenido

ERROR de PostgreSQL: declaración de cancelación debido a un conflicto con la recuperación

Solución:

No hay necesidad de tocar hot_standby_feedback. Como han mencionado otros, establecerlo en on puede hincharse maestro. Imagínese abrir una transacción en un esclavo y no cerrarla.

En su lugar, establezca max_standby_archive_delay y max_standby_streaming_delay a algún valor cuerdo:

# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s

De esta forma, las consultas sobre esclavos con una duración inferior a 900 segundos no se cancelarán. Si su carga de trabajo requiere consultas más largas, simplemente configure estas opciones en un valor más alto.

La ejecución de consultas en el servidor de espera activa es algo complicada: puede fallar, porque durante la consulta, algunas filas necesarias pueden actualizarse o eliminarse en el servidor primario. Como un primario no sabe que una consulta se inicia en un secundario, cree que puede limpiar (aspirar) versiones antiguas de sus filas. Luego, el secundario tiene que reproducir esta limpieza y debe cancelar por la fuerza todas las consultas que pueden usar estas filas.

Las consultas más largas se cancelarán con más frecuencia.

Puede solucionar esto iniciando una transacción de lectura repetible en el primario que realiza una consulta ficticia y luego permanece inactiva mientras se ejecuta una consulta real en el secundario. Su presencia evitará la aspiración de versiones de hileras antiguas en el primario.

Más sobre este tema y otras soluciones se explican en la sección Hot Standby – Manejo de conflictos de consultas en la documentación.

No es necesario iniciar transacciones inactivas en el maestro. En postgresql-9.1, la forma más directa de resolver este problema es configurando

hot_standby_feedback = on

Esto hará que el maestro sea consciente de las consultas de larga duración. De los documentos:

La primera opción es establecer el parámetro hot_standby_feedback, que evita que VACUUM elimine las filas muertas recientemente y así no se produzcan conflictos de limpieza.

¿Por qué no es este el valor predeterminado? Este parámetro se agregó después de la implementación inicial y es la única forma en que un modo de espera puede afectar a un maestro.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *