Re: Urgente, postgres down

Fransisco, gracias por tu comentario.

Despues que detuvimos el servidor apagado ejecutamos un vacuum en la base
de datos que tenia *datfrozenxid* por encima de los 2
billones...actualmente tiene 1.92 billones
Todas las tablas tienen relfrozenxid por debajo de mil millones

Autovacuum estuvo trabajando sin problema pero estaba usando
configuraciones erroreas que lo hacian lento para una base de datos que
ejecuta miles de writing transaction sin utilizar un connection pool, en un
momento estuve revisando el numero de dead_tup mientras autovacuum estaba
trabajando en esa tabla y el numero en vez de disminuir estaba aumentando.
La base de datos tine 880 tablas + otras base de datos (pequenas) y las
tablas de postgres.
Name Value
Current Proposal
autovacuum_vacuum_cost_limit 200 1000 or 2000
autovacuum_vacuum_cost_delay (ms) 20 20
vacuum_cost_page_hit 1 1
vacuum_cost_page_miss 10 10
vacuum_cost_page_dirty 20 20

autovacuum_vacuum_scale_factor 0.4 0.1
autovacuum_vacuum_threshold 50 10000
autovacuum_max_workers 3 6
autovacuum_naptime (s) 60

En estos momentos estoy preocupando porque siento que viene otro shutdown
pronto porque *datfrozenxid se esta acercando cada vez mas a los
2billones.*
*Ah el servidor esta corriendo actualmente solo que esta ejecutando toda la
cache de las casi 8 horas que estuvo fuera de servicio...*

On Thu, Feb 7, 2019 at 6:24 AM Francisco Olarte <folarte(at)peoplecall(dot)com>
wrote:

> Carlos:
>
> On Thu, Feb 7, 2019 at 1:01 AM Carlos T. Groero Carmona
> <ctonetg(at)gmail(dot)com> wrote:
> > El servidor de BD se cayo, actualmente caido, tratando de resolverlo..
> > tratando de ejectutar el vacuum solicitado...responde esto
> > ERROR: database is not accepting commands to avoid wraparound data loss
> in database "db_production" HINT: Stop the postmaster and use a standalone
> backend to vacuum that database. You might also need to commit or roll back
> old prepared transactions.
> > siguiendo estos articulos tratando de resolverlo...
> > https://access.redhat.com/solutions/269323
> >
> https://community.arubanetworks.com/t5/Monitoring-Management-Location/Using-a-standalone-backend-to-vacuum-database-quot-postgres-quot/ta-p/169522
> > pero no puedo conectar al postmaster...any idea..please...
>
> Lo estas haciendo mal, casi seguro. "Conectar al postmaster" es lo que
> se hace contra un servidor en red, para cosas como esta ( que es de
> emergencia ) se para y se lo levanta en local ( para que nadie
> interfiera ).
>
> Supongo que has leido la doc un poco, pero lo que te esta pasando es
> que el server esta mu malito, lo que es raro salvo que hayas quitado
> el autovacuum o hayas pegado con algun bug o tengas alguna marcianada
> como prepared transactions.
>
> Esta tan malito que NO PUEDE levantarse como servidor en red ( mas
> bien NO QUIERE, porque esta en un estado en el que potencialmente
> puede joderse de forma irrecuperable ), y tienes que levantarlo en
> modo monousuario, un modo que tiene en el que se levanta en la consola
> y acepta que le teclees comandos. Esto se hace asi para que nadie
> interfiera mientras haces reparaciones de emergencia y para que seas
> mucho mas cuidadoso ( aun te puedes cargar el servidor en modo
> monousuario ).
>
> Las instrucciones de las paginas que citan son bastante faciles, no
> deberias tener problemas. Si los tienes es fundamental que pongas mas
> datos:
> - Version del servidor y del SO en el que esta instalado.
> - Las versiones de clientes NO hacen falta, porque en este tipo de
> emergencias TODO se hace en el servidor.
> - Si has hecho alguna cosa en la consola, una copia ( en texto mejor )
> de lo que has hecho y ha pasado, ante la duda copia de mas, desde que
> paras el servidor palante.
> - Si el servidor esta en una maquina distinta de la que usas
> habitualmente ( se me ocurre el clasico "esta en un redhat que no
> conozco mucho y soy usuario de windows conectando con el putty", o
> viceversa ), o estas conectando a el con ssh o similar, indicalo por
> si acaso ( yo p.e. doy por hecho que los problemas de estar en una
> conexion remota por ssh o rdesktop o similar los sabes resolver si no
> indicas expresamente ).
>
> No es rutinario, pero la gente pega con este problema rutinariamente y
> se arregla ( eso si, downtime tienes, no te pongas nervioso ).
>
> Todo esto puede ser redundante, pero la escasez de datos en tu primer
> mail sugiere que te puede hacer falta, si no es asi ignoralo.
>
> Francisco Olarte.
>