Re: Demoting master to slave without an rsync...is it safe?

From: Alex Lai <alai(at)sesda2(dot)com>
To: Chris Redekop <chris(at)replicon(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Demoting master to slave without an rsync...is it safe?
Date: 2011-09-06 16:48:37
Message-ID: 4E664EE5.2010208@sesda2.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Chris Redekop wrote:
> I have a master+slave set up using asynchronous streaming replication.
> If I do a graceful (-fast) shutdown of the master, and then promote
> the slave to master, my understanding is that I should not have any
> data loss. At that point in order to bring the old master back up as
> a slave the docs say I should do a base-backup etc....however I've
> found that simply setting recovery_target_timeline='latest' does allow
> the old master to start back up as a slave, and everything appears to
> be happy, all data seems to be synced properly. My question is, is
> this safe to do? It's a very attractive option as it removes a
> significant amount of load from the master server for planned
> switch-overs (maintenance/upgrades/whatever). Thanks!
Hi Chris,

I don't have an answer for you, but I am doing the kind of tests you are
doing.
I tested the following cases:
case-1 Shutdown master, slave still available for read-only
Then started master, both master and slave works properly

case-2 Shutdown slave while master still running and lots of inserts
and updates
After 10 minutes, started slave, and it catched up with the
changes within minutes

case-3 Assume master is crash, shutdown master, slave in read-only and
waiting for the WAL update.
Then, I touch the recovery failover file indicated in
recovery.conf.
The slave changed into read-write mode.
A lots of inserts and update to the slave now become
master. (I am not sure its a good idea, but in real case if master down
I want the slave can act as master while waiting for the another slave
available.)
I am not sure the changes are updated to arch_replicate
directory where are the old Master write to it.
I real case I need to make sure no changes to the new master
right after the fail over.
Then copy the postgresql.conf and recovery.conf to the
$PGDATA of the new master then restart the database.
Then resyn $PGDATA to another location of the old master
host, then copy slave conf to the new $PGDATA. I have about 1TB of
database can take up to 30 minues.
Then restart the new slave, every thing works.

I have two questions:
(1) Did you set recovery_target_timeline='latest' in both master and slave?
(2) Did you make any changes after promote the slave to be master?

--

Best regards,

Alex Lai
OMI SIPS DBA ADNET Systems , Inc.
7515 Mission Drive,
Suite A100 Lanham, MD 20706
301-352-4657 (phone)
301-352-0437 (fax)
alai(at)sesda2(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2011-09-06 16:56:56 Re: Backend process that won't die
Previous Message Susan Cassidy 2011-09-06 16:05:15 Backend process that won't die