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