Re: Problem with streaming replication, backups, and recovery (9.0.x)

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/

In response to

Responses

Browse pgsql-hackers by date

  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