On Thu, Aug 02, 2007 at 12:26:47PM +0400, Dimitri Gritsenko wrote: > Goal - having 1 master and 2 standbies - make switchover in the way , that > except minimal downtime - there was always 1 running master and 2 warm > standbies. > > Lets say i have 3 hosts (1,2,3) , 1 master and 2 warm standbies . ( M1 SB2 > SB3) > Each SB gets (Master rsyncs from his side to SB) archived wal files from > master and recovers in continues way untill triggered to start as master., > also it gets incomplete wals from pg_xlog dir . > Switchover looks for me like this. > 1. M1 stops , all sync crons stopped. > 2. Do last rsync of archived wals and pg_xlog to SB2 , SB3 > 3. SB2 triggered to start , it recovers last incomplete wals from pg_xlog > and starts (becomes M2), and starts cron rsync to SB3 > 4. SB3 does nothing , it continues get recover wal archives which now it > gets from M2. (Question - is it ok ? It looks like new archived wal files > from M2 should be valid without any changes) Hrm... I'm not sure if that's OK... I seem to recall something about a difference in WAL file numbering when a PITR recovery is done (promoting slave to master in your case). I suggest trying it; if it works I don't expect there to be any hidden issues. > 5. What happens on host 1 (former master) is a question. It needs to become > a SB1 . Do i need to make large rsync of whole db from M2 (like during SB > install) or i can just keep old data and start db in recovery mode , getting > new wal files? No, you can't take a data directory that's been run outside of recovery mode and push it back into a recovery mode (which is essentially what you're asking for). You'll need to rsync from host 2 to host 1 and start recovery from there. There's a very critical thing you've overlooked, too. You have to ensure that slaves will *only* get archived logs from the master. This means that if you switch masters, you have to guarantee that the old master won't be archiving any logfiles anymore. Another possibility would be to ensure that things are configured so that each machine will archive to a different location. -- Decibel!, aka Jim Nasby decibel@xxxxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment:
pgpLQAuEjicoc.pgp
Description: PGP signature
