> 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)
Uhmm, chico recordar que la replicación como todo hay que monitorearla, yo a consejo Nagios para ello, y usar algo como PgpoolAdmind, rpmgr para el control de failover, swithover, failback > 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. >>>> >>> >>> >> >> > -- Saludos, Gilberto Castillo ETECSA, La Habana, Cuba - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
