Re: Urgente, postgres down

Carlos:

On Thu, Feb 14, 2019 at 9:42 PM Carlos T. Groero Carmona
<ctonetg(at)gmail(dot)com> wrote:
>> **** NO NO NO!
> Francisco agradesco mucho su comentario y honestidad, no se preocupe, no se si haya notado que a veces demoro en contestar sus correos cuando necesito revisar algo en mi servidor, es porque antes realizo un procedimiento de prueba en 3 servidores diferentes y 6 diferentes base de datos antes de llegar a mi servidor en production y mi base de datos en producion.

Si, ademas por la redaccion me da la impresion de que estas en
America, con lo que hay desfase horario. Pero bueno, dados los
horarios que a veces llevan los sysops, igual eso hace que coincidamos
mas que lo contratio. Puse eso porque me dio la impresion de que no
estaba transmitiendo bien y prefiero que me tomes por tonto a que te
cargues algo.

....snip-snip.....

> Las queries que estoy usando son:
> 1.Para encontrar las edades (XID) por base de datos:
> SELECT
> datname,
> max(age(datfrozenxid)),
> round(max(age(datfrozenxid)) / 2100000000.0 * 100.0, 3) AS percentage_transaction_ids_used
> FROM pg_database
> -- where datallowconn = true
> group by datname
> order by 2 desc;

Aqui es parte de lo que yo decia de template0/1, que son DB inmutables:

datfrozenxid xid : All transaction IDs before this one have been
replaced with a permanent (“frozen”) transaction ID in this database.
This is used to track whether the database needs to be vacuumed in
order to prevent transaction ID wraparound or to allow pg_xact to be
shrunk. It is the minimum of the per-table pg_class.relfrozenxid
values.

En una base de datos inalterada puedes tener todas las tuplas "frozen"
y datfrozenxid no se mueve del valor que se metio al hacerlo. Es
decir, datfrozenxid peligroso es una condicion necesaria, pero no
suficiente, para tener problemas.

> 2.Una vez que detecto la base de datos con mayor IXD me conecto y reviso cuales son las tablas con mayor XID usando esta otra query:
> SELECT
> c.oid::regclass as table_name,
> greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age,
> round((age(c.relfrozenxid)) / 2100000000.0 * 100.0, 2) AS percentage,
> pg_size_pretty(pg_table_size(c.oid)) as table_size
> FROM
> pg_class c
> LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
> WHERE c.relkind = 'r'
> ORDER BY 2 DESC
> LIMIT 20;

Y aqui tenemos una definicion similar:

relfrozenxid xid All transaction IDs before this one have been
replaced with a permanent (“frozen”) transaction ID in this table.
This is used to track whether the table needs to be vacuumed in order
to prevent transaction ID wraparound or to allow pg_xact to be shrunk.
Zero (InvalidTransactionId) if the relation is not a table.

Echandole una mirada a lo que tengo disponible, que no es mucho aqui,
me da la impresion de que las templates solo necesitan "aspirarse"
para actualizar los parametros, que estan casi todas frozen.

Por lo que veo por ahi, NO puedes hacer vacuum a template0, si a
template1, de vez en cuando ( CREO recordar que era recomendable un
full, o quizas full+freeze, despues de cambiarla, ya que es
basicamente RO ). Me parece que la razon de que cambien las id es que
algunas tablas del sistema ( databases y roles, IIRC ) son compartidas
entre todas las BD, con lo que se ven en template0/1 aunque no esten
de verdad ahi.

De hecho initdb tiene esto en el fuente: (
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/initdb/initdb.c;h=fd50a809ea4f0096c27b7f082dc9576f372e379e;hb=HEAD
)
2033 /*
2034 * clean everything up in template1
2035 */
2036 static void
2037 vacuum_db(FILE *cmdfd)
2038 {
2039 /* Run analyze before VACUUM so the statistics are frozen. */
2040 PG_CMD_PUTS("ANALYZE;\n\nVACUUM FREEZE;\n\n");
2041 }

Y justo debajo de eso tienes la rutina que crea template0 a partir de
1. Como sospechaba se tiene buen cuidado de dejarlas bien
congeladitas. Cotilleando por ese fuente se ve bastante bien como lo
hace, y los comentarios ( como el de #2039 arriba ) son instructivos.

> 3. Entonces realizo manualmente vacuum a las tablas que me ayudaran a abajar el XID
> vacuum analyze verbose table_name;
> Asi es como he ido manejando la situacion con aquellas base de datos que me permiten conectarme, el unico problema es template0, que no me deja

¿ No has hecho ningun vacuum completo ? Yo probaria a hacerle uno (
que por lo que veo se puede y debe hacer ) a template1 ( o, si
quieres, primero a postgres, o incluso a un scratch-monkey, pero como
tienes servidores de pruebas si hay que hacerlo habras de probarlo en
alguno dee sos antes ) para ver si eso altera alguna tabla compartida.
Toy mayor, pero creo que en los tiempos heroicos de la 7.x, o algo
asi, tuve que hacer alguna cosas de esas.

> Bueno por ahora voy a realizar algunas pruebas de como utilizando autovacuum_freze_max_age tratar que autovacuum centre su esfuerzos en template0, les dejo saber el resultado de mis pruebas.
> Si se les ocurre alguna otra alternativa para disminuir el XID en template0 se los agradecere.

Como te decia, prueba un vacuum (freeze) total en template1 o
postgres. Por lo que leo por ahi el autovacuum PUEDE hacerlo en
template0 aunque no permitan conexiones. La cosa a mirar es si el
datfrozenxid de template0 cambia al hacer un vaccum en template1 /
postgres / una vacia ( deberia ser muy rapido ).

Francisco Olarte.