Re: StreaminReplication 1 + 2

Anthony, perdón la ignorancia, intento comprender todo el proceso, ¿que
pasa si el standby está caído el tiempo suficiente para que los wal que
permanecen en el master no le alcancen para ponerse al día? el standby se
da cuenta de tal situación? nos tira un error como para que busquemos los
wal necesarios? O levanta como si nada hubiera pasado? (si esto sucede se
armaría un caos replicativo! :-) así que no creo)

El 15 de abril de 2016, 10:38, Anthony Sotolongo <asotolongo(at)gmail(dot)com>
escribió:

> Hola Guillermo, desde hace un tiempo cada vez que hago la configuración de
> replica streaming replication no hago la tranferencia de archivos WAL al
> standby, solo los guardo en un sitio(un disco aparte), pero no para
> aplicarlos en la replica(*puede que lo este haciendo mal, pero hasta
> ahora ha funcionado y si hay una caida, utilizo los WAL almacenados para
> reconstruir* ), también he considerado que la conexion entre el maestro y
> el esclavo es buena y la latencia no es grande, así que si hay retraso en
> la replica con un num bastante grande de wal_keep_segment se me sincroniza
> sin problemas luego. Así que la opción que planteas de hacer un archivado
> en el mismo server A, me ha funcionado, y hasta ahora no los he pasado a
> los demás servers, me ha bastado con los que envia el walsender :D.
>
>
> saludos
>
> PD: es algo muy personal con los escenarios que he tenido y me ha
> funcionado
>
>
> On 15/04/16 09:15, Guillermo E. Villanueva wrote:
>
> Anthony muchas gracias por tu respuesta.
> Si es posible, van mas consultas....
>
> Manteniendome en el esquema:
> A (master) ↔ B (standby)
> A (master) ↔ C (standby)
>
> Recomiendan que con ambos standby combine streaming replication +
> transferencia de archivos WAL ?
>
> En el caso de un solo standby en mi* archive_command* yo usaba un único
> scp, ahora al tener mas de un standby? Consideran que es una buena opción
> hacer el archivado en el mismo server A y luego con cron o algún método
> pasarlos a B y C ?
>
> Desde ya , muchas gracias por sus respuestas.
>
> Saludos
>
>
> El 14 de abril de 2016, 15:22, Anthony Sotolongo <asotolongo(at)gmail(dot)com>
> escribió:
>
>> HOla Guillermo, te comento entre lineas
>>
>> On 12/04/16 01:12, Guillermo E. Villanueva wrote:
>>
>>> Buenas noches amigos, estoy necesitando armar la siguiente topología
>>> con postgres 9.3 (linux).
>>> Un servidor principal (A) de lectura y escritura.
>>> Un servidor standby (B) de solo lectura capaz de levantar ante caidas de
>>> (A).
>>> Un servidor standby (C) de solo lectura.
>>>
>>> Una idea inicial era que (A) replique con (B) y con (C).
>>> Pero también podrá ser que (A) replique con (B) y que (B) replique con
>>> (C) en cascada, pero solo me interesa que (B) pueda levantar como principal
>>> ante caídas.
>>>
>>> Cuál de las dos opciones es factible? Cuál consideran que es mejor? Hay
>>> alguna guía para realizar la configuración?
>>>
>> Las dos se puede implementar, todo depende que tus características,
>> escenario y necesidades, una vez implemente la de la cascada para que B
>> ocupara el master cuando A fallara y C seguía viendo a B como su master,
>> pero la variante 1 la puedes implementar también, todo está cuando caiga A
>> decirle a C que siga a B, tengo entendido que repmgr te puede ser útil en
>> eso, o implementas tu mismo el mecanismo para hacer el cambio de que C siga
>> a B
>>
>>
>> Saludos
>>
>>
>>
>>> Desde ya muchas gracias por la orientación que me puedan dar.
>>>
>>> Saludos.
>>>
>>
>>
>
>