Re: dump y restore de base de datos grande

From: Federico Sansone <fsansone(at)gmail(dot)com>
To: Martín Marqués <martin(dot)marques(at)gmail(dot)com>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, POSTGRES <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: dump y restore de base de datos grande
Date: 2014-02-05 16:58:45
Message-ID: CAH=2PdO7aOBC=+su=R-ED2eKZ+XQB85V1S1Jh4qO_1DCNZ1UyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Muchas gracias por las respuestas. Jaime, entiendo que las opciones que
recomiendas son ideales, pero actualmente la base de datos esta configurada
en dos nodos en cluster que mueven el directorio de datos de un lado a otro
cuando se para el servicio en alguno de los nodos. (Entiendo que usan una
herramienta estándar de red hat).

De mi poquísima experiencia con Slony recuerdo que tuve problemas por falta
de indices únicos en tablas. Me fue en su momento muy engorroso configurar
lo que necesitaba Slony para funcionar bien, pero lo investigare. Si
conocen alguna lista de temas a tener resueltos para validar si es una
opción, lo agradeceré.

Igualmente les cuento que la duda sobre el dump y restore pasa también por
la necesidad de recuperar de una ejecución de pg_resetxlog. En el proceso
de prueba del restore, no repare en la configuración de archiving de wal y
se lleno el disco lo cual genero un crash de la base.

De lo que pude encontrar en la web, y por la necesidad de recuperar el
sistema que vive con la base, hice un backup de los logs y ejecute el
reset. Entiendo que posterior a esto debo hacer un dump/restore que en este
caso no sera inmediato.

Esto me tiene hoy ademas intentando resolver los problemas surgidos del
reset, como unos warning que mencionan: "relcache reference leak: realtion
"pg_largeobject_loid_pn_index" not closed" y "relcache reference leak:
realtion "pg_largeobject" not closed"

Hoy quizá necesito que me recomienden con que cuidados avanzar en la
estabilización de la base.

Lamento convertir una consulta en un pedido de auxilio. Pero quisiera
comenzar a ser mas cuidadoso (aunque tarde...)

Muchas gracias

Saludos

Federico

2014-02-05 Martín Marqués <martin(dot)marques(at)gmail(dot)com>:

> El día 5 de febrero de 2014, 2:43, Jaime Casanova
> <jaime(at)2ndquadrant(dot)com> escribió:
> > 2014-02-04 Federico Sansone <fsansone(at)gmail(dot)com>:
> >> Hola lista! es mi primer contacto y espero que me puedan dar una mano y
> >> eventualmente hacer mi humilde aporte.
> >>
> >> Estoy necesitando hacer un dump y restore de una base que no tuvo
> >> mantenimiento por 3 años, y tiene un peso e 1.1Tb. Plantee hacerlo así
> >> porque nunca finalizo los vacuum que se intentaron hacer y me pareció
> que
> >> era matar varios pájaros de un tiro y un borrón y cuenta nueva para
> comenzar
> >> a darle soporte.
> >>
> >
> > Hacer un dump de una base de 1.1 Tb no va a ser muy divertido.
> > Aunque si lograrías el efecto que buscas puede tomar mucho tiempo.
> > Otra alternativa que tienes es usar Slony o Londiste para crear una
> > replica de la base de datos, debido a la forma en que estas
> > herramientas replican esa nueva base estará en mejor condición que la
> > original. Una vez que se haya replicado puedes hacer un failover.
>
> Yo vería de resolver los problemas de VACUUM (si es que lo hay), o en
> su defecto, ya que estás haciendo dump + restore o creando el nuevo
> cluster por replicación por trigger, directamente actualizar a una
> versión más actual.
>
> Como estás usando VACUUM sobre la base? Hay alguna tabla donde se
> quede trabajando más? Cuanto está seteado maintenance_work_mem?
>
> Saludos,
>
> --
> Martín Marqués
> select 'martin.marques' || '@' || 'gmail.com'
> DBA, Programador, Administrador
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2014-02-05 17:22:22 Re: Alguna forma de actualizar secuencias adentro de una funcion
Previous Message Hellmuth Vargas 2014-02-05 16:09:39 Re: Milisegundos entre dos campos