Muchas gracias a los tres por vuestros comentarios y aportaciones. Sobre el tema de la ubicacion de los xlog, intentare probar a ponerlos en ambos sitios y ver con que va mejor y os cuento los resultados para que sirvan al resto.
El tema del cluster con DRDB es como esta puesto hasta ahora, pero la idea era usar el balanceo de carga, ya que tenemos problemas de rendimiento y pienso que el balanceo puede ayudar a solucionarlos. Sobre los problemas con las funciones volatiles, muchas gracias, no los conocia, me informare mas sobre el tema y hablare con desarrollo para ver el tipo de consultas que lanzamos y comprobar su compatibilidad. Gracias El 22 de diciembre de 2009 23:28, Jaime Casanova < [email protected]> escribió: > 2009/12/22 Cesar Martin <[email protected]>: > > > > En el servidor nuevo había pensado poner Postgres en la versión 8.3.9 y > > pgpool-II en versión 2.3.1 con Heartbit para hacer un cluster e intentar > > repartir las consultas entre ambos servidores. > > el problema con pgpool es que replica sentencias, y aunque la nueva > version dice trabajar correctamente al replicar funciones volatiles > como now() lo hace porque sabe que hacer para ese caso especifico. > Todo es cosa que en tu aplicacion tengas una funcion volatil que > pgpool no conozca (por ejemplo una creada por ti) y la replicacion ya > no funcionará bien... > > Es más hay SELECT´s no deben ser escogidos para balanceo de carga, por > ejemplo los que ejecuten una función volatil. Imagina esta: > SELECT actualiza_vista_materializada(); o SELECT elimina_procesos_viejos(); > > todas esas sentencias que no deben ser escogidas para balanceo de > carga sino que deben replicarse deben ir antecedidas de el comentario > /*REPLICATION*/ > > en otras palabras, no es tan transparente como quisieramos hay que > verificar que las consultas que estas ejecutando en tu aplicación son > seguras para pgpool > > -- > Atentamente, > Jaime Casanova > Soporte y capacitación de PostgreSQL > Asesoría y desarrollo de sistemas > Guayaquil - Ecuador > Cel. +59387171157 > -- César Martín Pérez [email protected]
