Re: Usando WAL en memoria junto con streaming replication

Eduardo:

2016-07-07 19:40 GMT+02:00 Eduardo Morras <emorrasg(at)yahoo(dot)es>:
...
>> 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.

Dado que la RAM es mas cara que el disco.... De todas formas mide en
algun desktop a ver cuanta diferencia te hace meter los logs en RAM,
ten en cuenta que al disminuirte la RAM disponible por el disco RAM
tendras que ponerle mas y pagarla. Los xlog tampoco van tan lentos,
salvo que le zurres muchisimo. Por otro lado ten en cuenta que el
esclavo tiene que guardarlos en almacenamiento estable y aplicarlos de
todos modos.

>> 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.

No, no es eso lo que digo. Lo que digo es que en condiciones normales
si tu haces un reboot, y tienes la maquina bien configurada, el
postgres tiene el xlog ahi cuando rearranca, que no se lo que se queda
dentro. La cosa es si puede hacer un pgctl stop smart, borrar el
directorio de xlog, pgctl start y sigue funcionando.

>> 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.

Yo he bajado pg_restores de horas a minutos tuneando configuraciones,
y el sync es una de ellas.

Francisco Olarte.

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