From: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Problem with streaming replication, backups, and recovery (9.0.x) |
Date: | 2011-03-29 09:49:17 |
Message-ID: | 20110329094917.GC16699@depesz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 29, 2011 at 11:13:07AM +0900, Fujii Masao wrote:
> Yes, it's intentional. In streaming replication, at first the master must stream
> a backup history file to the standby in order to let it know the recovery ending
> position. But streaming replication doesn't have ability to send a text file, so
> we changed the code so that the recovery ending position was also written as
> WAL record which can be streamed.
ok, this makes sense.
> BTW, in my system, I use another trick to take a base backup from the
> standby:
>
> (All of these operations are expected to be performed on the standby)
> (1) Run CHECKPOINT
> (2) Copy pg_control to temporary area
> (3) Take a base backup of $PGDATA
> (4) Copy back pg_control from temporary area to the backup taken in (2).
> (5) Calculate the recovery ending position from current pg_control in
> $PGDATA by using pg_controldata
>
> When recovery starts from that backup, it doesn't automatically check
> whether it has reached the ending position or not. So the user needs to
> check that manually.
> Yeah, this trick is very fragile and complicated. I'd like to improve the way
> in 9.2.
I know about it, but I feel very worried about doing stuff like this -
i.e. meddling with internal files of pg.
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 | Fujii Masao | 2011-03-29 11:27:21 | Re: Problem with streaming replication, backups, and recovery (9.0.x) |
Previous Message | hubert depesz lubaczewski | 2011-03-29 09:46:39 | Re: Problem with streaming replication, backups, and recovery (9.0.x) |