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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers