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
