Muchas gracias por tu respuesta Anthony, veamos que otras sugerencias tenemos. Saludos!
El 15 de abril de 2016, 10:38, Anthony Sotolongo <asotolo...@gmail.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 <asotolo...@gmail.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. >>> >> >> > >
