Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] help, server caído

Estimado Jose, lo que tu indicas es factible con BBDD que trabajan con
horarios acotados, pero cuando tienes una BBDD en producción de alta
disponibilidad, te aconsejo sacar respaldo en un ambiente de prueba,
estimar tiempos de trabajo y luego planificar la Mantención, considerando
los horarios Pick del Motor.

atte

El 4 de julio de 2013 16:09, Jose Moreira - Know How <
jmoreira(at)knowhow(dot)com(dot)uy> escribió:

> No tengo contacto con otros administradores Postgres por eso me intresa
> saber como son las "best practices".
> La pregunta es, no es recomendable (por no decir obligatorio) bajar la
> aplicacion para que no hayan conexiones antes de ejecuar un vacuum manual?
> Lo que le pasó a Guillermo es un ejemplo de lo que pasa si no se baja.
> No sé , pregunto.
>
> gracias
>
> jose
>
>
>
> On 04/07/2013 03:57 p.m., Alvaro Herrera wrote:
>
>> Guillermo E. Villanueva escribió:
>>
>>> Muchas gracias Alvaro y Jaime, les cuento que leí sus mensajes y no sabía
>>> como cancelar, entré a la misma consola ssh y presioné control + C y ...
>>> yes! se canceló! muchas gracias. La verdad que tenía miedo de dañar los
>>> datos de la tabla.
>>> El VACUUM abre muchas conexiones a la vez?
>>>
>> No, sólo una.
>>
>> Me imagino que lo que pasó es que otra conexión tratoó de hacer alguna
>> operación que requería un lock en la tabla que entra en conflicto con el
>> ShareUpdateExclusive de VACUUM, y por lo tanto se bloqueó; y todos los
>> accesos de ahí en adelante quedan bloqueados detrás de esa otra
>> conexión. Para depurar esto deberías mirar pg_locks buscando filas con
>> granted=false, y correlacionar eso con lo que están tratando de hacer
>> esas conexiones en pg_stat_activity.
>>
>> Ahora, ¿por qué podría llegar a pasar esto? Es fácil: si las
>> operaciones que toman locks pesados en esa tabla son comunes, entonces
>> autovacuum nunca podría completar un ciclo sobre esa tabla, porque éste
>> se "suicida" cuando encuentra que está bloqueando otras conexiones. (Un
>> VACUUM ejecutado manualmente no tiene este comportamiento). La solución
>> es simple pero no necesariamente fácil: tienes que hacer que tus
>> aplicaciones no traten de obtener locks pesados muy seguido sobre las
>> tablas. Por lo menos debería poder ejecutarse un vacuum completo desde
>> que eso pasa una vez hasta la vez siguiente.
>>
>> Éxito,
>>
>>
>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> **)
> Para cambiar tu suscripción:
> http://www.postgresql.org/**mailpref/pgsql-es-ayuda<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
>

--
Sin más que decir se despide de Usted, muy atentamente

Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema
Especialista en ISO 27001 e ITIL

Cuenta Twitter: @caeries

Santiago - Chile