Re: StreaminReplication 1 + 2

Muchas gracias por tu respuesta Anthony, veamos que otras sugerencias
tenemos.
Saludos!

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