Hola, Jaime.
Muy amable por su respuesta. Estoy totalmente de acuerdo que desactivar el
autovacuum es dar un paso atrás tecnológicamente hablando.
La solución de activar hot_standby_feedback la había descartado por el impacto
en la replicación, pero gracias a su explicación, creo ahora mismo que sería la
mejor solución.
Solamente me queda una duda: como comentabamos los parámetros
max_standby_*_delay, tiene sentido que en la instancia sincrona tiendan a cero
y en la asincrona sean un poco más laxos.
El problema de "ERROR: cancelando la sentencia debido a un conflicto con la
recuperación" ¿solo afecta cuando una sentencia lanzada en la standby ve
modificado su MVCC por la modificación de la réplica procedente de la primaria,
es decir insert, updates, y deletes, o solo se ve afectada cuando en la
replicación se eliminan filas muertas producto del autovacuum en la primaria?
Si activamos el parámetro hot_standby_feedback creo que funcionaría así:
1 - Se lanza consulta en la standby.
2 - se lanza autovacuum en la primaria.
3 - La standby le indica que hay una sentencia sobre una tabla especifica y
sobre ella no hará limpieza.
4 - Se hace un insert, un update, y un delete sobre la misma tabla en la
primaria.
5 - Se replican los cambios automáticamente.
6 - La standby esperará a que resuelva la sentencia el tiempo que indique el
parámetro max_standby_*_delay.
7 - Si la sentencia dura más que el parámetro...
¿Aquí que sucede?
a) No hay fallo alguno pues la replicación de estos datos en la tabla por
la que corre la sentencia no afecta a las filas que va a leer la sentencia en
curso de la standby. El update podrá afectar a una fila leída de esta
sentencia, pero recogerá el valor que esté almacenado para el mismo MVCC.
b) Provoca el mismo fallo que al principio, pues al realizar cualquier
cambio sobre la tabla, se recalcula el hash de las filas, y se actualiza ese
dato del MVCC en cada cabecera de la fila.
c) Si es otro escenario que no planteo, por favor me ayudaría mucho que me
lo plantease para poder entenderlo.
Muchas gracias por tu contestación
Un saludo.
Saludos.
Iván Poyatos Luque
Área Bases de Datos
-----Mensaje original-----
De: Jaime Casanova <jcasa...@systemguards.com.ec>
Enviado el: lunes, 5 de junio de 2023 23:27
Para: Iván Poyatos Luque <ipoyat...@hiberus.com>
CC: pgsql-es-ayuda@lists.postgresql.org
Asunto: Re: Consultas en nodos standby con HA
On Wed, May 31, 2023 at 7:12 AM Iván Poyatos Luque <ipoyat...@hiberus.com>
wrote:
>
> Tengo un sistema con un nodo primario, y dos hot_standby, uno con streaming
> síncrono y otro asíncrono. La versión es 9.3.
>
Empezaré por mencionar que 9.3 está obsoleto hace varios años atras (Nov 8,
2018): https://www.postgresql.org/support/versioning/
>
> En los nodos standby se lanzan consultas de solo lectura y aquellas que
> superan el umbral establecido por el parámetro max_standby_archive_delay o
> max_standby_streaming_delay provocan un conflicto de versión de snapshot que
> termina reflejándose en la pg_stat_database_conflicts.
>
> Estos nodos de standby son la HA, por lo tanto, es también un requisito que
> estén actualizados lo antes posible.
>
>
> Hemos deshabilitado el autovacuum en la primaria para que no replique la
> limpieza de las filas muertas en las standby, por lo tanto, utilizar el
> parámetro hot_standby_feedback creemos que carece de sentido ya que no existe
> tal limpieza. Hemos programado una tarea que realizará un vacuum a las 3 de
> la madrugada.
>
Nunca es buena idea desactivar el autovacuum, conozco montones de personas que
darán una explicación clara y creible de porque su caso es distinto y apagar el
autovacuum para ellos es "la" solución. No lo es.
Nunca. Apagues. El. Autovacuum.
Ahora, te explico porque tu solución está tomando la ruta equivocada.
Al apagar el autovacuum y ejecutar un VACUUM a las 3am estás causando que la
limpieza de registros ocurra solo a esa hora *para todas las tablas*.
Mientras que hot_standby_feedback en on, solo evitará que el primario limpie
los registros en las tablas que se hayan modificado mientras la consulta más
antigua en la réplica aún se esté ejecutando (es decir, esos registros
modificados en esa ventana de tiempo no se podrán limpiar los más antiguos si).
>
> Los parámetros max_standby_archive_delay o max_standby_streaming_delay
> podemos subirlos a valores altos como 10 minutos, pero siempre tendrás el
> riesgo de que, si una sentencia dura más, tendrás un conflicto. Sin entrar a
> valorar el rendimiento de una consulta de 10 minutos, es solo un ejemplo.
>
Si tienes un nodo standby sincrónico, supongo que tus scripts para failover lo
consideran el primer candidato en caso de que falle el primario.
puedes tener valores distintos para los parámetros max_standby_*_delay en cada
servidor, considerando esa diferencia
>
> Vemos además un riesgo añadido, el nodo con replicación síncrona tiene el
> parámetro synchronous_commit a on, es decir que la primaria antes de dar el
> ok a la transacción esperará que el dato esté replicado en la standby
> sincrona. Es decir que aumentar el parámetro max_standby_streaming_delay en
> la standby síncrona creemos que puede afectar al rendimiento en la primaria,
> pues si coincide con una consulta en la standby, no se aplicarán los cambios
> de la replicación hasta que la consulta finalice, o expire el tiempo indicado
> en este parámetro, y el cliente vería retrasado el commit de su transacción.
>
no. synchronous_commit, al menos en 9.3, solo asegura, cuando hay servidores
sincrónicos, que la transacción se haya replicado hasta la memoria del standby
(remote_write) o hasta el disco (en el WAL pertinente; on); pero no espera a
que se apliquen los cambios (que se hagan visibles). Esto significa que los
parámetros max_standby_*_delay y synchronous_commit no se afectan entre ellos,
el rendimiento que tienes ahora será el mismo.
A partir de 9.6 se agregú un valor remote_apply, que ese si puede afectar el
rendimiento en el primario.
--
Jaime Casanova
SYSTEMGUARDS S.A.
Director de servicios profesionales
