Re: Urgente, postgres down

Hola Carlos, basada en una experiencia similar, aunque no tan agresiva cómo
esa que comentas, recomiendo analizar las tablas más críticas respecto a
las transacciones y ajustes los valores de vaccum/Freeze en ellas(las
tablas puntuales), pues las configuraciones genéricas en el archivo de
configuración, valga la redundancia en mi caso no me resolvió mucho, aquí
no hay fórmulas perfectas respecto al tema, solo depende de tu escenario
puntual para hacer ajustes al respecto. Te lo comento pues es muy probable,
que de esas tablas algunas sean las responsables de tu problema y no todas,
así si vas a tocar los vaccum/freeze los ajustes por tablas.

Así profundiza en tu escenario y analiza en que te puede ayudar las
personalización de estas variables por tablas, tal.vez este ahí tú solución.

Saludos

El jue., 7 de feb. de 2019 1:40 p. m., Carlos T. Groero Carmona <
ctonetg(at)gmail(dot)com> escribió:

> 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.
>>
>