Date: Tue, 8 Apr 2014 00:33:50 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Lazaro Ruben Garcia Martinez <lgarciam@vnz.uci.cu>
Cc: ALEXANDER JOSE <aangelj@hotmail.com>,
 "pgsql-es-ayuda@postgresql.org" <pgsql-es-ayuda@postgresql.org>
Subject: Re: Postgresql 9.3 en cluster
Message-ID: <20140408033350.GI5822@eldon.alvh.no-ip.org>
References: <BAY182-W10D5E6C1ECD558D09C3DDBA56F0@phx.gbl>
 <48623.192.168.207.54.1396620001.squirrel@webmail.etecsa.cu>
 <BAY182-W332E86D390DB30938C942FA56B0@phx.gbl>
 <294D3D02D5E18D42827B2ECFEADEB688D11595EA3C@mx-interno.vnz.uci.cu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <294D3D02D5E18D42827B2ECFEADEB688D11595EA3C@mx-interno.vnz.uci.cu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-es-ayuda-owner@postgresql.org

Lazaro Ruben Garcia Martinez escribió:
> Mi recomendación es postgresql activo-pasivo, replicación con
> streaming replication y utilizar por delante a pgpool. En un entorno
> que tengo instalado existen dos pgpool, para temas de alta
> disponibilidad con watchdog, pool de conexiones y failover automático,
> en un tiempo tengo pensado activar la cache de pgpool para aumentar el
> rendimiento. Hasta el momento todo ha marchado sin problemas.

Cuidado con el failover, sobre todo si es automático.  Tuvimos un
cliente con problemas de corrupción de datos porque el procedimiento de
failover no era kosher.  El problema se multiplicó porque como el
failover era automático, se hizo repetidas veces en cierta ocasión que
tuvieron exceso de carga, y se propagó.

Para los que no saben, "kosher" es un término técnico que en castellano
significa "by the book".

Saludos

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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