Hi,
On 2013-07-26 13:19:34 +0900, Sawada Masahiko wrote:
> When the slave server starts, the slave server perform the following
> steps in StartupXLOG():
> 1. Read latest CheckPoint record LSN from pg_control file.
> 2. Try to fetch CheckPoint record from pg_xlog directory at first.
> ( The server try to read up to prior CheckPoint record from pg_contrl file)
> 3. If there is not in pg_xlog, the slave server requests CheckPoint
> record to the primary server.
> in #3, it works only when StandbyMode is true. For StandbyMode is to
> true, database cluster state should be "DB_SHUTDOWNED" (it is one of
> the conditions).
> that is, slave server can try to fetch checkpoint record from the
> master server after slave server was successful completion.
It also will fetch the xlog from remote when we've found a backup label
(the read_backup_label() branch in StartupXLOG() will set StandbyMode to
true). Which will be the case if we're recovering from something like a
base backup.
The reason we don't fetch from remote if there's no backup label *and*
the last checkpoint wasn't a shutdown checkpoint is that that's doing
*local* crash recovery. Usually it will happen because we needed to
restart after a crash (or immediate restart which basically is the
same).
There's one valid case where you can get into the situation otherwise as
well, which is that the *entire* database directory has been copied via
an atomic snapshot. But in that case you *need* to also snapshot
pg_xlog.
Maybe there's another valid scenario?
> If this problem is solved, there is possible of that we can failback
> by removing the all WAL record which is in pg_xlog before server
> starts as the slave server.
> ( And we also use "synchronous_transfer" which I'm proposing, I think
> we can fail-back without taking full backup surely)
I still have *massive* doubts about the concept. But anyway, if you want
to do so, you should generate a backup label that specifies the startup
location.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services