2013/5/9 Martín Marqués <martin.marq...@gmail.com>: > El día 9 de mayo de 2013 18:47, Jaime Casanova <ja...@2ndquadrant.com> > escribió: >> 2013/5/9 Jaime Casanova <ja...@2ndquadrant.com>: >>> >>> Solo puedes hacer esto de forma segura si 1) ejecutas >>> pg_start_backup() en la base previo a hacer el clonado y 2) tienes un >>> archivo de wal de donde leer los segmentos de wal desde el momento en >>> que iniciaste el clonado hasta que termino. De lo contrario puedes >>> obtener un mensaje como el que te dio o peor aun: una base >>> inconsistente sin ningún aviso. >>> >> >> solo para completar la respuesta: >> la otra alternativa si estas en 9.0 o superior es que 1) incrementas >> wal_keep_segmentas en el servidor que vas a clonar, 2) ejecutes >> pg_start_backup() e inicies el disco clonado primero como un servidor >> hot standby (basicamente que uses al maestro como archivo de wal >> temporal) luego si regresas wal_keep_segments a 0. >> >> Para nada de eso se necesita parar la base > > Pero si estas en pg_start_backup() los archivos de WAL no se deberian > perder (sin importar el valor de wal_keep_segments). >
pg_start_backup() no fuerza a que se acumule el wal si mal no recuerdo, prueba con una base muy grande y un checkpoint_segments pequeño y verás. Pero en todo caso aun así en un proceso de clonado de un disco dependes del orden en que el proceso de clonado copie las cosas, si lo hace por bloques físicos es posible que termines copiando "pg_xlog" antes que los directorios de alguna base, así que a veces funcionará y a veces no. Es mas seguro aumentar a wal_keep_segments en el maestro y siempre hacer el clonado luego de haber ejecutado pg_start_backup() -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
