ERROR de PostgreSQL: cancelación de declaración debido a conflicto con la recuperación
Recibo el siguiente error al ejecutar una consulta en una base de datos PostgreSQL en modo de espera. La consulta que causa el error funciona bien durante 1 mes, pero cuando realiza una consulta durante más de 1 mes, se produce un error.
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed
¿Alguna sugerencia de cómo resolverlo? Gracias
No es necesario tocar hot_standby_feedback. Como otros han mencionado, configurarlo en onpuede inflar al maestro. Imagínese abrir una transacción en un esclavo y no cerrarla.
En su lugar, establezca max_standby_archive_delayy max_standby_streaming_delayvalores sensatos:
# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s
De esta forma no se cancelarán consultas sobre esclavos con una duración inferior a 900 segundos. Si su carga de trabajo requiere consultas más largas, simplemente configure estas opciones en un valor más alto.
Los documentos de Postgres analizan esto con cierta profundidad . El consejo clave a partir de ahí es:
Si el servidor en espera está destinado a ejecutar consultas de larga duración, entonces puede ser preferible un valor de retraso alto o incluso infinito [in
max_standby_archive_delayy ].max_standby_streaming_delay
y
Los usuarios deben tener claro que las tablas que se actualizan con regularidad y en gran medida en el servidor principal provocarán rápidamente la cancelación de consultas de mayor duración en el servidor en espera. En tales casos, la configuración de un valor finito para max_standby_archive_delay o max_standby_streaming_delay puede considerarse similar a la configuración de Statement_timeout.
También puede considerar configurar Vacuum_defer_cleanup_age ( en el primario ) en combinación con los retrasos máximos en espera. Como dicen los médicos:
Otra opción es aumentar Vacuum_defer_cleanup_age en el servidor principal, de modo que las filas muertas no se limpien tan rápido como lo harían normalmente. Esto permitirá que las consultas tengan más tiempo para ejecutarse antes de que se cancelen en el modo de espera, sin tener que establecer un max_standby_streaming_delay alto.
Ejecutar consultas en un servidor de reserva activa es algo complicado: puede fallar porque durante la consulta algunas filas necesarias pueden actualizarse o eliminarse en el servidor principal. Como el primario no sabe que se inició una consulta en el secundario, cree que puede limpiar (aspirar) versiones antiguas de sus filas. Luego, el sistema secundario tiene que volver a reproducir esta limpieza y tiene que cancelar por la fuerza todas las consultas que puedan usar estas filas.
Las consultas más largas se cancelarán con más frecuencia.
Puede solucionar este problema 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 impedirá la aspiración de versiones antiguas de fila en primaria.
Se explica más sobre este tema y otras soluciones 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 esté al tanto de las consultas de larga duración. De los documentos :
La primera opción es configurar el parámetro hot_standby_feedback, que evita que VACUUM elimine filas recientemente muertas y, por lo tanto, 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.
