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 <cton...@gmail.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 <alvhe...@2ndquadrant.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 >> >
