On 02/27/2012 10:05 PM, Lucky Haryadi wrote:
3. When Master A fails to service, the database will failovered to Slave B by triggering with trigger file.
As soon as you trigger a standby, it changes it to a new timeline. At that point, the series of WAL files diverges. It's no longer possible to apply them to a system that is still on the original timeline, such as your original master A in this situation. There's a good reason for that. Let's say that A committed an additional transaction before it went down, but that commit wasn't replicated to B. You can't just move records from B over anymore in that case. The only way to make sure A is in sync again is to do a new base backup, which you can potentially accelerate using rsync to only copy what has changed. I see a lot of people try to bypass one of the steps recommended in the manual using various schemes like yours, and they usually have a bug like this in there--sometimes obvious like this, sometimes subtle. Trying to get too clever here is dangerous to your database.
Warning: pgsql-hackers is the mailing list for people to discuss the development of PostgreSQL, not how to use it. Questions like this should be asked on either the pgsql-admin or pgsql-general mailing list. I'm not going to answer additional questions like this from you here on this list, and I doubt anyone else will either.
-- Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
