2016-09-27 12:29 GMT-05:00 Alvaro Herrera <alvhe...@2ndquadrant.com>: > Mario Soto Cordones escribió: >> Estas en lo correcto, pero, depende del punto de vista que se mire, para >> "mi" Alta Disponibilidad es que mis usuarios nunca se enteren que se cayó >> tal o cual nodo (entiéndase por usuario cualquier aplicación), es por ese >> motivo que incluí en la ecuación el haproxy, Que me permite atender >> peticiones, no importando que nodo se cayó. > > OK. ¿qué pasa con el usuario que tenía una transacción de escritura en > la mitad cuando el maestro se cayó?
Coincido con Álvaro en que BDR no se debe usar a la ligera, antes de usarlo debes chequear que tu aplicación y BDR se entienden y lo más seguro es que eso significa modificar la aplicación para complacer los caprichos de BDR. Una vez dicho eso: Supón que tienes un nodo BDR en la ciudad UNO, un segundo nodo BDR en la ciudad DOS y un tercer nodo BDR en la ciudad TRES. Supón también que tus usuarios de la región UNO se conectan *siempre* al nodo BDR en la ciudad UNO, los de la región DOS al nodo de la ciudad DOS y los de la región TRES al nodo de la ciudad TRES. Y entonces falla el nodo de la ciudad DOS, los usuarios de ahí se verán afectados y deberás moverlos a otro nodo y repetir la transacción. Sin embargo, los usuarios de la región UNO y TRES no sintieron el problema. BDR si te puede proveer de una mejor Alta Disponibilidad, en el ejemplo anterior 2/3 de tus clientes no sintieron el fallo y el resto puedes reubicarlos y ponerlos a funcionar. Ahora, si todo lo que buscas es balanceo de carga BDR no es la solución sino servidores de solo lectura. -- Jaime Casanova www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services - 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
