estudia la opción realizar lo que quieres con un sistema de replicas, ejemplo symmectricDS, slony por mencionarte algunos pudiera ser cualquiera, asi no tendrías que parar el servicio y cuando termine de replicar solo cambias la conección y listo,
----- Mensaje original ----- De: "Ruben Fitó" <[email protected]> Para: "Cesar Martin" <[email protected]> CC: [email protected] Enviados: Viernes, 2 de Noviembre 2012 7:07:34 Asunto: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Backup en producción. Muchas gracias, Ha sido de gran ayuda. Y sólo por curiosidad, cómo incorporais los datos en la "nueva" BBDD, que se han insertado el la "antigua" BBDD durante el backup/restauración??? Por nuestro lado, tenemos la possibilidad de "simular" la entrada de datos que se han producido desde el inicio del backup, pero tengo ciertas dudas respecto a algunos serializables considerados llave primaria de algunas tablas. No se si me explico. Gracias. 2012/11/2 Cesar Martin < [email protected] > Mi BBDD tiene 300GB y varios triggers que rellenan tablas. Lo he restaurando con dump a un servidor y no ha habido ningún problema a pesar de que esta insertando datos constantemente. Eso si, lógicamente, si no cortas el acceso a la BBDD cuando saques el DUMP, ese dump no va a tener todos los cambios... Normalmente es mejor cortar el acceso a al BBDD, que perder datos, pero cada caso es distinto. En cualquier caso, saca el backup en formato binario (-Fc) y restauralo utilizando la opción --disable-triggers. Un saludo. El 2 de noviembre de 2012 11:20, Ruben Fitó < [email protected] > escribió: <blockquote> Gracias por responder, La nueva máquina tendrá la versión 9.1, por lo tanto necesitamos restaurar por backup/restore. Según he estado leyendo pg_dump hace el backup de una "foto" de la BBDD en el momento que inicia el proceso. Eso me tranquiliza, pero como soy un desconfiado, jeje, me gustaria saber si existe algun caso(que no sea problema de sistemas) en que el backup contuviera inconsistencia de datos. Mil Gracias. 2012/11/2 Cesar Martin < [email protected] > <blockquote> Hola, Si lo vas a pasar a otra maquina, pero vas a mantener la versión de postgres y al menos el mismo tipo de OS sin tener en cuanta la versión, tal vez te salga mas rentable hacer un rsync de la carpeta "data" a la maquina nueva que con una conexión GB debería tardar muy poco. Una vez realizado el primer rsync, lanzas un segundo y un tercero, que veras que van tardando cada vez menos. Cuando el tiempo de copiado, sea muy pequeño, paras la primera BD, haces el ultimo rsync y arrancas la nueva BBDD, levantando la misma IP, etc. Esa forma es la que menos tiempo de interrupción del servicio requiere, al menos que yo sepa. Un saludo. El 2 de noviembre de 2012 09:47, Ruben Fitó < [email protected] > escribió: <blockquote> Hola a todos, Tengo una duda respecto al proceso de backup de postgres. Tenemos una BBDD 8.3 que se encuentra en producción i siempre estan entrando transacciones contínuamente. Estas TX, actualizan ciertos campos de otras tablas con triggers. Actualmente, el backup que realizamos és con pg_dumb, por lo tanto nos genera un "*.sql". Ahora hay necesiadad de traspasar la BBDD a otra màquina mas potente. La duda que tengo és que, si durante el proceso de backup con pg_dump (35 min aprox) entran nuevas TX(i lanzan estos triggers) existirà un problema con la integridad de los datos??, o postgresql crea un "punto de backup" que hace caso omiso de las nuevas TX??? Hay alguna diferencia con el problema si lo hacemos en binario, pg_dump -F c??? Gracias. -- Ruben Fitó Software Engineer Ubiquat Technologies, SL r.fito @ub iquat.com www.ubiquat.com Tota la informació continguda en aquest document i arxius adjunts és CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per error, si us plau elimini'l i posi's en contacte amb l'emissor. All information contained in this document and any attachments are CONFIDENTIAL and protected under trade secret laws. If you receive this message by mistake, please delete it and notify it immediately to the sender. -- César Martín Pérez [email protected] </blockquote> -- Ruben Fitó Software Engineer Ubiquat Technologies, SL r.fito @ub iquat.com www.ubiquat.com Tota la informació continguda en aquest document i arxius adjunts és CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per error, si us plau elimini'l i posi's en contacte amb l'emissor. All information contained in this document and any attachments are CONFIDENTIAL and protected under trade secret laws. If you receive this message by mistake, please delete it and notify it immediately to the sender. </blockquote> -- César Martín Pérez [email protected] </blockquote> -- Ruben Fitó Software Engineer Ubiquat Technologies, SL r.fito @ub iquat.com www.ubiquat.com Tota la informació continguda en aquest document i arxius adjunts és CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per error, si us plau elimini'l i posi's en contacte amb l'emissor. All information contained in this document and any attachments are CONFIDENTIAL and protected under trade secret laws. If you receive this message by mistake, please delete it and notify it immediately to the sender. 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci
