Re: Usando WAL en memoria junto con streaming replication

On Thu, 7 Jul 2016 17:21:48 +0200
Francisco Olarte <folarte(at)peoplecall(dot)com> wrote:

> Hola Eduardo:
>
> 2016-07-07 17:02 GMT+02:00 Eduardo Morras <emorrasg(at)yahoo(dot)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(at)postgresql(dot)org) Para cambiar tu suscripci_n:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda

--- ---
Eduardo Morras <emorrasg(at)yahoo(dot)es>

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda