Re: Problem with streaming replication, backups, and recovery (9.0.x)
От | hubert depesz lubaczewski |
---|---|
Тема | Re: Problem with streaming replication, backups, and recovery (9.0.x) |
Дата | |
Msg-id | 20110329094142.GA16699@depesz.com обсуждение исходный текст |
Ответ на | Re: Problem with streaming replication, backups, and recovery (9.0.x) ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Problem with streaming replication, backups, and
recovery (9.0.x)
|
Список | 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/
В списке pgsql-hackers по дате отправления: