To: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
From: CS DBA <cs_dba@consistentstate.com>
Subject: D.R. Site Failover (Streaming Replication) - user access / network
 options
Message-ID: <56DF026E.6010401@consistentstate.com>
Date: Tue, 8 Mar 2016 09:48:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Hi All;

We are assisting a client with an Oracle to PostgreSQL conversion. They 
did not have any replication with Oracle due to the version they ran, 
however moving to PostgreSQL they want to setup a local HOT Standby and 
a remote / DR Site standby. Setting up the Standby's is easy enough, 
we've setup standby's multiple times and automated failover lots of 
times as well.  We have in the past leveraged a number of approaches to 
keep a failover seamless to the app. In most DR / remote site cases 
we've recommended that the full stack be replicated so if we completely 
loose a site (or cloud region) then we switch to the secondary site, 
promote the secondary / DR site standby to a master and we're back in 
business.

I do however have a few questions related to this, I'm interested to 
find out what others have done here, in particular how do you go about 
moving end users (assuming a web app is the end user entry point) to 
point seamlessly to the secondary site?  Also how have you all dealt 
with the possible split brain issue (i.e. we fail over, then the primary 
site comes back up and existing/old connections to the old site then 
write to the old master)

Thanks in advance for your feedback....


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin