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 <[email protected]>: > El día 5 de febrero de 2014, 2:43, Jaime Casanova > <[email protected]> escribió: > > 2014-02-04 Federico Sansone <[email protected]>: > >> 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 >
