From: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Problem with streaming replication, backups, and recovery (9.0.x) |
Date: | 2011-03-29 09:41:42 |
Message-ID: | 20110329094142.GA16699@depesz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
> I have a theory. Can you try it in what would be the failure case,
> but run an explicit a CHECKPOINT on the master, wait for
> pg_controldata to show that checkpoint on the slave, and (as soon as
> you see that) try to trigger the slave to come up in production?
=$ ( pg_controldata master/; pg_controldata slave2/ ) | grep "Latest checkpoint location:"
Latest checkpoint location: 0/2D000058
Latest checkpoint location: 0/2C000058
=$ psql -p 54001 -c "checkpoint"
CHECKPOINT
=$ ( pg_controldata master/; pg_controldata slave2/ ) | grep "Latest checkpoint location:"
Latest checkpoint location: 0/2E000058
Latest checkpoint location: 0/2C000058
... ~ 1.5 minute later
=$ ( pg_controldata master/; pg_controldata slave2/ ) | grep "Latest checkpoint location:"
Latest checkpoint location: 0/2E000058
Latest checkpoint location: 0/2E000058
=$ touch /home/depesz/slave2/finish.recovery
it worked. now the slave2 is working as stand alone.
what does it tell us? will any work happening after checkpoint break it anyway?
Best regards,
depesz
--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.com/
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2011-03-29 09:46:39 | Re: Problem with streaming replication, backups, and recovery (9.0.x) |
Previous Message | Dimitri Fontaine | 2011-03-29 07:49:16 | Re: Additional options for Sync Replication |