Re: Error: Found xmin xxxx from before relfrozenxid xxxx

From: "Carlos T(dot) Groero Carmona" <ctonetg(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Martín Marqués <martin(at)2ndquadrant(dot)com>, Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Error: Found xmin xxxx from before relfrozenxid xxxx
Date: 2019-05-28 21:42:13
Message-ID: CABh6Tc1SUYaQ7Zd8Yw=U+MajKA+OEuFs58iR5L3ej4_gcXzhMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hola lista, solo quiero darles un update de lo que hice para resolver este
asunto y que funciono, espero que nadie pase por mi amarga experiencia pero
por si les pasa tengan una posible salida.

Casualmente tenia unos servidores disponibles los cuales ivamos a utilizar
hace algun tiempo, pero se habia cancelado por migrar hacia Azure.

Lo que hice fue replicar (SR) desde mi DR a uno de estos servidores, y una
vez todo listo y coordinado pues lo promovi a master y actualize a postgres
9.6, si debo decir que me tomo mas de lo planeado para estar online otra
vez, pues el analyze tomo horas y horas sin resultados, le hice analyze a
una BD de menos de 10MB y nunca termino, al final despues de varios dias
sin efecto lo cancele con -9 porque no se queria detener, pues ya
autovacuum habia limpiado todo el cluster para evitar el wraparround.

Con eso se resolvio el problema de la tabla correucta (pg_daatabase).

De paso aproveche y puse un F5 como LB y dos pgbouncer como en algun
momento me aconsejaron (utilizar connection pooling) y es increible como
esas herramientas estan ayudando cuando tenemos picos en la carga del
sistema.

Una vez mas gracias or sus consejos.
Carlos

On Tue, Apr 30, 2019 at 12:59 PM Carlos T. Groero Carmona <ctonetg(at)gmail(dot)com>
wrote:

> Ante todo gracias por sus comentarios,
>
> Alvaro, desde que puse un pie en esta compania he empujado para migrar a
> una version superior soportada, pero nunca lo han aprobado, espero que esta
> amarga sitacion los haga escarmentar y aprueben la migracion que tanto he
> pedido.
>
> Pero bueno mi trabajo ahora es tratar de buscar una solucion y evitar como
> DBA que mi servidor caiga y aprecio mushisimo los consejos e ideas que
> todos me brindan.
> A continuacion algunos datos:
>
> postgres=# select distinct relname, relfrozenxid from pg_class where
> relname = 'pg_database';
>
> relname | relfrozenxid
>
> -------------+--------------
>
> pg_database | 935164618
>
> (1 row)
>
>
> postgres=# vacuum ANALYZE pg_database;
>
> ERROR: found xmin 1983484116 from before relfrozenxid 4007722125
>
> postgres=# SELECT
>
> datname,
>
> max(age(datfrozenxid)),
>
> round(max(age(datfrozenxid)) / 2100000000.0 * 100.0, 3) AS
> percentage_transaction_ids_used
>
> FROM pg_database
>
> group by datname
>
> order by 2 desc limit 1;
>
> datname | max | percentage_transaction_ids_used
>
> ---------+------------+---------------------------------
>
> auth_db | 1114181073 | 53.056
>
> (1 row)
>
> En estos momentos mi avg XID (diario) es ~30Millions por lo que me da unos
> 25 dias antes que el servidor se apague para evitar wraparrounds.
>
> Mi tabla affectada es pg_database asi que:
>
> postgres=# select ctid, xmin, datname, datfrozenxid, datminmxid from
> pg_database;
>
> ctid | xmin | datname | datfrozenxid | datminmxid
>
> --------+------------+------------------+--------------+------------
>
> (0,1) | 2 | ofx_production | 935164548 | 2
>
> (0,2) | 2 | auth_db | 935163740 | 2
>
> (0,3) | 2 | postgres | 935164618 | 2
>
> (0,4) | 2 | semi_temp | 944965842 | 2
>
> (0,6) | 2 | sami_production | 935327190 | 2
>
> (0,7) | 2 | locations | 935164198 | 2
>
> (0,8) | 2 | locations_backup | 935164338 | 2
>
> (0,9) | 2 | template1 | 944966462 | 2
>
> (0,11) | 1983484116 | template0 | 944966014 | 2
>
> (9 rows)
>
> La tupla que esta corructa es template0, creo que todo empezo cuando tuve
> que actualizar el datallowconn en templace 0 para poder ejecutar vacuum
> en esa base de datos y una vez terminaba el vacuum pues la actualizava de
> nuevo, en fin, no estoy seguro, tengo el mismo cron job corriendo en otros
> servidores para hacerle vacuum a todas las DB en el servidor y no tengo
> este problema.
>
> Alvaro, me sugieres hacer un update en la tabla pg_database lo que no me
> queda claro si set xmin = 2 or set xmin=935164618
>
> Una pregunta, suponiendo que esto no funcione, migrar a una version
> superior soportada podria ayudarme a resolver este problema?
>
> Gracias,
> Carlos
>
> On Mon, Apr 29, 2019 at 11:40 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:
>
>> Carlos T. Groero Carmona escribió:
>>
>> > Entonces, algo que se pueda hacer para resolver esta situacion y poder
>> > ejecutar vacuum?
>>
>> creo que la alternativa era (después de tomar un respaldo, por si algo
>> se rompe) hacer un UPDATE del pg_class.relfrozenxid en las tablas
>> afectadas en la base de dato afectada -- volverlo atrás al valor del
>> xmin que te indica, y luego ejecutar vacuum sobre esa tabla en esa base
>> de datos. Rezar para que nada se rompa. No sé si es necesario repetir
>> en otras BDs.
>>
>> Creo que lo mejor sería detener toda actividad de la BD hasta que hayas
>> resuelto.
>>
>> Otra opción: tomar un pg_dump completo, borrar todo (initdb), restaurar
>> el dump.
>>
>> La próxima vez que te digan que tienes que actualizar a una BD
>> soportada, no esperar hasta que los bichos te piquen. Ojalá tu
>> experiencia le sirviera de lección a todos los demás también.
>>
>> --
>> Álvaro Herrera https://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Edwin Quijada 2019-05-29 16:10:25 Seleccionar records de intervalo de 15m
Previous Message Daymel Bonne 2019-05-27 15:06:43 Re: Dudas varias pglogical