From: | Anthony Sotolongo <asotolongo(at)gmail(dot)com> |
---|---|
To: | "Guillermo E(dot) Villanueva" <guillermovil(at)gmail(dot)com>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: StreaminReplication 1 + 2 |
Date: | 2016-04-14 18:22:59 |
Message-ID: | 570FE003.1050702@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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.
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
From | Date | Subject | |
---|---|---|---|
Next Message | Kernel | 2016-04-15 07:46:48 | Re: chmod desde postgres/plsql -MI SOLUCION |
Previous Message | Horacio Miranda | 2016-04-14 04:59:29 | Re: chmod desde postgres/plsql |