ERROR de PostgreSQL: cancelación de declaración debido a un 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 sobre cómo resolver? Gracias
5 answers
Ejecutar consultas en el servidor hot-standby es algo complicado: puede fallar, porque durante la consulta algunas filas necesarias pueden actualizarse o eliminarse en el primario. Como un primario no sabe que una consulta se inicia en secundaria piensa que puede limpiar (vacío) versiones antiguas de sus filas. Luego secondary tiene que volver a reproducir esta limpieza, y tiene que 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 primaria que hace una consulta ficticia y luego se queda inactiva mientras se ejecuta una consulta real en secundaria. Su presencia evitará la aspiración de versiones de fila antiguas en primaria.
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-01-30 08:20:47
No hay necesidad de iniciar transacciones inactivas en el maestro. En postgresql-9.1 la forma más directa de resolver este problema es estableciendo
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 EVITE eliminar filas recientemente muertas y, por lo tanto, no se produzcan conflictos de limpieza.
¿Por qué no es el valor predeterminado? Este parámetro fue añadido después del inicial implementación y es la única forma en que un standby puede afectar a un maestro.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-07-24 08:16:02
Como se indica aquí acerca de hot_standby_feedback = on:
Bueno, la desventaja de esto es que el standby puede hinchar al maestro, lo que podría ser sorprendente para algunas personas, también
Y aquí:
¿Con qué configuración de max_standby_streaming_delay? Yo preferiría por defecto que a -1 que por defecto hot_standby_feedback en. De esa manera que hacer en el modo de espera solo afecta al modo de espera
Así que agregué
max_standby_streaming_delay = -1
Y no más pg_dump error para nosotros, ni maestro hinchar:)
Para la instancia de AWS RDS, marque http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-10-03 20:23:22
No hay necesidad de tocar hot_standby_feedback. Como otros han mencionado, configurarlo a on puede hinchar a master. Imagina abrir una transacción en un esclavo y no cerrarla.
En su lugar, establezca max_standby_archive_delay y max_standby_streaming_delay en 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 manera, 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 establezca estas opciones en un valor más alto.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-01 11:58:22
Los datos de la tabla en el servidor esclavo hot standby se modifican mientras se ejecuta una consulta de larga duración. Una solución (PostgreSQL 9.1+) para asegurarse de que los datos de la tabla no se modifican es suspender la replicación y reanudar después de la consulta:
select pg_xlog_replay_pause(); -- suspend
select * from foo; -- your query
select pg_xlog_replay_resume(); --resume
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-10-05 08:56:02