Error de consulta de Postgresql ERROR: cancelación de la declaración debido a un conflicto con la recuperación

Detalles:

Descripción del escenario

Aquí estamos en un entorno de replicación de streaming y el repositorio está copiado desde la red en vivo El nodo de respaldo en el servidor extrae datos, lo que provoca el error anterior.

El principio es muy simple: el nodo maestro realiza DDL o DML en las tablas relevantes. Cuando la billetera se reproduce en el nodo de respaldo, la consulta del nodo de respaldo aún está en progreso. Se producirá un conflicto y se eliminará la declaración de consulta del nodo de respaldo. Se informa el error anterior.

La siguiente figura demuestra brevemente el principio de informe de errores. Los conflictos son causados ​​por la ACTUALIZACIÓN en DML. Las versiones de filas inconsistentes causarán errores relacionados.

Como se puede ver en la figura anterior, hay un parámetro max_standby_streaming_delay cuyo valor predeterminado es 30 segundos, lo que significa que al aspirar, si todavía hay cosas en los datos relevantes que deben limpiarse, Se considera que ha ocurrido un conflicto y se espera. El valor establecido para este parámetro es 30 segundos. Después de 30 segundos, la conexión se interrumpe y se informa el error anterior. Por lo tanto, puede ser DDL, como eliminar tabla, truncar tabla, eliminar base de datos, eliminar espacio de tabla, etc., o puede ser DML, y declaraciones como eliminar y actualizar causarán errores.

Entonces, hay dos formas de lidiar con esto: lidiar con DDL y lidiar con DML

Para evitar DDL, debe configurar el parámetro max_standby_streaming_delay en -1 para que espere hasta el final de la declaración de consulta.

Para evitar conflictos causados ​​por DML (es decir, VACUUM), por supuesto, también puede utilizar el método anterior. Aquí se introduce otro parámetro hot_standby_feedback. Puede activar (activar) este parámetro para evitarlo. .

El principio de hot_standby_feedback es muy simple: notificar periódicamente al nodo principal el ID mínimo de transacción activa del nodo en espera, de modo que el nodo principal pueda ser misericordioso con los datos que aún necesitan estas transacciones. al realizar VACÍO.

La ventaja de configurar hot_standby_feedback es que puede reducir la posibilidad de conflictos de replicación cuando el nodo de respaldo ejecuta consultas, pero también tiene una desventaja, es decir, retrasará la recuperación de datos de la primera tabla cerrada. del nodo primario, lo que resulta en datos hinchados; en casos extremos, si el tiempo de transacción del nodo de respaldo es muy largo y las tablas involucradas en las operaciones DML son muy frecuentes, entonces el hinchamiento de la tabla será muy grave. En casos extremos, si el tiempo de transacción del nodo de respaldo es muy largo y las operaciones DML en la tabla son muy frecuentes, la hinchazón de la tabla será muy grave.

Considere también configurar el parámetro Vacuum_defer_cleanup_age, que retrasa la limpieza de las filas muertas para que las consultas en el nodo de respaldo puedan leerlas. El valor predeterminado es 0. Este parámetro se establece en el nodo maestro y también lo mide el nodo maestro, por lo que es difícil determinar qué valor establecer es un valor válido, y si la cantidad de cosas en el nodo maestro crece rápidamente, será difícil determinar qué valor establecer. Si la cantidad de cosas en el nodo principal crece rápidamente, las filas muertas se limpiarán rápidamente y tendrán poco impacto en los conflictos de consultas en el nodo de respaldo. Por lo tanto, personalmente no recomiendo configurar este parámetro para resolver los errores causados ​​por el nodo principal. problemas anteriores.

Resumen:

Habilitar max_standby_streaming_delay o max_standby_archive_delay tiene sus inconvenientes. Si el nodo en espera tiene mucho tiempo para hacerlo, entonces el nodo en espera no podrá seguir el ritmo del nodo maestro durante mucho tiempo. El nodo primario y el nodo en espera no podrán seguir el ritmo del progreso. Los mismos datos si hay varios nodos de reserva en cascada, la situación será aún peor. Si hay varios nodos de respaldo en cascada, las consecuencias serán aún más desastrosas.

Si esto es solo hot_standby_feedback, puede hacer que las tablas relacionadas se inflen. Si la empresa consulta, actualiza y elimina con frecuencia, entonces el procesamiento DML de estas tablas infladas definitivamente será ineficiente y afectará la respuesta empresarial.

Además, el efecto de Vacuum_defer_cleanup_age no es ideal, se refleja principalmente en los indicadores del nodo maestro, por lo que no se recomienda configurarlo y no haremos un estudio en profundidad aquí.

Referencia:

/dazuiba008/java/article/details/104966409