| From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Hot Standby Failover Scenario |
| Date: | 2012-02-28 16:40:29 |
| Message-ID: | 4F4D037D.1000200@2ndQuadrant.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-02-28 16:46:39 | Re: Initial 9.2 pgbench write results |
| Previous Message | Jeff Janes | 2012-02-28 16:36:41 | Re: Initial 9.2 pgbench write results |