Si no necesitas replicar estructura, puedes utilizar una herramienta como Slony para la replicación de datos y la cual combinada con heartbeat, por ejemplo, también te permite obtener una solución de alta disponibilidad.
Saludos From: pgsql-es-ayuda-ow...@postgresql.org [mailto:pgsql-es-ayuda-ow...@postgresql.org] On Behalf Of Pablo Siciliano Sent: Monday, April 09, 2012 8:36 PM To: Jaime Casanova Cc: Lazaro Ruben Garcia Martinez; pgsql-es-ayuda@postgresql.org Subject: Re: [pgsql-es-ayuda] Pgpool y postgresql 8.1 Hola Jaime, 2012/4/9 Jaime Casanova <ja...@2ndquadrant.com> > > 2012/4/9 Lazaro Ruben Garcia Martinez <lgarc...@uci.cu> 2012/4/9 Pablo Siciliano <pablo.sicili...@gmail.com> > > Hola Lazaro. > > >> Hola Pablo. Nunca he utilizado Pgpool-II con PostgreSQL 8.1, pero en la documentación oficial de Pgpool- >> II mencionan que la recuperación utilizando PITR, solo es posible a partir de la versión 8.2 de PostgreSQL. >> Yo te recomiendo revisar la documentación y te fijes en la sección ¨Online recovery with rsync¨. > > Te estas refiriendo a la documentacion de postgresql 8.1 o a la de pgpool II? Justamente en la > documentacion de postgresql es que me baso para hacer la pregunta. El tema que tengo es que el > directorio data es enorme como para hacer un rsync al momento de levantar un nodo. > ese pgpool es solo para alta disponibilidad, verdad? es decir no podras hacer balanceo de carga. es verdad que no hay pg_switch_xlog() pero podrias crear una tu. crea una funcion llamada asi que cree una tabla temporal y la llene con datos y borre la tabla (tendras que hacer calculos buenos para determinar cuando fue suficiente para generar un nuevo archivo de wal o simplemente calcular 16MB y de seguro que paso a un nuevo archivo). y luego ejecutas esa funcion cada X minutos en un cron En principio no, la idea no es hacer balanceo de carga. Era una alternativa, pero me parecio un poco extrema. Voy a estudiar mejor en xlog.c como hacen el calculo en los sources de postgresql y tal vez siga por ahi. >> Otra recomendación, y la más importante es que logres realizar una actualización de la versión de Postgres, porque esa es muy antigua. >> > > Si, lo se ... Como explique de antemano en mi post no esta dentro de ambito de desicion pedirle a mi > cliente que haga esa migracion, pero soy conciente de que es viejisima. De hecho, una de las primeras > cosas que hice cuando empece a trabajar con ellos fue sugerir esa migracion, a la cual se negaron porque > el equipo de desarrollo "no tenia tiempo" para revisar casts que en versiones mas nuevas de postgresql > deben ser explicitos. > yo que tu, los haría firmar un papel que diga que cuando pierdan información por usar una versión de postgres que no ha tenido soporte desde Nov 2010 (y que por lo tanto por mas de un año y medio no se ha hecho ningún intento (ni se hará) de corregir ninguna falla que pueda tener) tu no te responsabilizas y veras que como tu te lo tomas en serio ellos también lo harán. Otra buena idea ... El día que algo falle todos descubrirán que por algún motivo fue culpa tuya, aunque tu hoy culpes a otros. No culpo a nadie. Trabajo para terceros, que toman sus desiciones empresariales acorde a montones de cosas que no vienen al caso y sobre las que tampoco yo tengo control. Puedo llegar a cuestionar el tema y levantar una alerta e incluso cubrirme, pero no mas que eso. Agradezco tus comentarios, pero me parece que cabe aclarar que mis clientes toman sus desiciones haciendo una evaluacion de proyectos coherente, aunque haga ruido que tengan una version de postgresql tan vieja ... Y yo no suelo tomar mis proyectos a la ligera. Este de hecho no es el caso, y ya habia dado recomendaciones por escrito al respecto. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Gracias por tu ayuda, Jaime. Saludos. Pablo. 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
