On Thu, 7 Jul 2016 17:21:48 +0200 Francisco Olarte <fola...@peoplecall.com> wrote:
> Hola Eduardo: > > 2016-07-07 17:02 GMT+02:00 Eduardo Morras <emorr...@yahoo.es>: > > Muy buenas, estoy haciendo unas pruebas en desarrollo con 2 > > postgres, Maestro-Esclavo. La carga de trabajo va a ser > > principalmente de lectura. Para ello voy a poner el Maestro en un > > servidor pequeño y el esclavo en el grande, usando pgpool para > > hacer las consultas de lectura en el Esclavo. Quiero probar si > > crear un disco en memoria en el Maestro para contener el directorio > > xlog (los wal) aumentara y en que medida la performance del > > Maestro. Puedo dedicar un enlace de red para la transferencia de > > los wal al esclavo, por lo que habria un delay minimo entre Maestro > > y Esclavo. > > Mmm, me poner los pelos como escarpias. Yo que tu mediria primero, si > el esclavo es rapido Y lleva la carga principal no creo que vayas a > ganar demasiado ( y to personalmente no lo haria sin una ganacia bien > grande ). Es mas que nada para evitar gastar mucho dinero en el servidor Maestro e invertirlo en el Esclavo, que es el que se va a llevar el trabajo duro. Los recursos monetarios son limitados. > > La consulta es si una caida del Maestro y no mandar todos los wal > > al Esclavo pueden provocar una corrupcion en este ultimo. Entiendo > > que no, el Esclavo quedaria a la espera de los wals faltantes, no > > recibiria el heartbeet del Maestro y haria un roolback de las > > transacciones a medio hacer > > Hombre, normalmente una caida del maestro se recupera al levantarlo, > lo que no es asi en tu caso. El maestro se pudre y ante cualquier > caida tendrias que promover el esclavo a maestro, que tendra el > retardo que le toque, y reconstruir tu sistema desde ahi ( recopiar el > maestro, volverlos a girar ). > > Es mas, haz una prueba pero me da que el maestro, salvo que hagas > algun truco para guardar el xlog, se pudriria no solo cuando se > ahostie, sino tambien cuando pares la maquina ( la prueba es facil, > coge un cluster, paralo, borra el directorio de xlog, arranca a ver > que pasa ), en cuyo caso vas a tener mas movidas aun con los upgrades. Ahi depende de como pares la maquina. Siempre parar primero Postgres (pg_ctl stop -m smart) y despues hacer el shutdown. Nunca confio en que llamar a shutdown directamente pueda parar correctamente postgres o cualquier otro demonio mio, tiene la mala costumbre de matar todo pasado un timeout y dejar las cosas a medio hacer. > > Ya se que el Maestro quedaria corrompido, eso no importa, puedo > > usar el Esclavo de lectura para realizar una recuperacion o incluso > > otro servidor (pequeño tambien) para almacenar los wals, backups u > > otro esclavo en sr. > > Yo, antes que esto, mediria bien a ver que pasa, y si realmente no da > la velocidad probaria antes de hacer esto con un fsync=off en el > maestro ( que hace que solo se te pudra cuando se ahostia la maquina, > no cuando se la pega el server, y en las pruebas que he hecho yo > habitualmente va a todo trapo ( lo uso mucho para actualizaciones, > backup, fsync off, transformaciones, fsync on ). Si, esta parte Alvaro tambien la ha comentado. Lo suelo usar en sqlite, pero no habia pensado en usarlo con Postgres. > Francisco Olarte. Muchas gracias > - > 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 --- --- Eduardo Morras <emorr...@yahoo.es> - 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
