Thanks a lot for the answer, Michael (and sorry for the slow response)! So, if I understand what you're saying correctly, I'm seeing this behavior because wal-e keeps fetching wal files from s3 regardless of this trigger_file, and these fetched wal files are in pg_wal (or pg_xlog), therefore Postgres just tries to restore whatever available in pg_wal before the failover. Or, even if there is no file in pg_wal, it still tries to fetch from the "archive" (s3). In other words, if I would like to do "immediate failover" (and do not care about WAL files available in archive or in pg_wal), I should be tweaking restore_command so that no further fetching/restoring happens. Is it... accurate?
Thanks, Keiko On Mon, Mar 19, 2018 at 9:28 PM, Michael Paquier <mich...@paquier.xyz> wrote: > On Mon, Mar 19, 2018 at 01:27:21PM -0700, Keiko Oda wrote: > > I'm seeing the following behavior with a trigger file which is very > > confusing to me, I'd like to get some advice of what is the expected > > behavior of the trigger file with the standby. > > This portion from the docs includes your answer: > https://www.postgresql.org/docs/devel/static/warm- > standby.html#STANDBY-SERVER-OPERATION > "Standby mode is exited and the server switches to normal operation when > pg_ctl promote is run or a trigger file is found (trigger_file). Before > failover, any WAL immediately available in the archive or in pg_wal will > be restored, but no attempt is made to connect to the master. > > So when creating a trigger file or signaling for promotion, any WAL > files available are first fetched, and then promotion happens. In your > case all the WAL segments from the archives are retrieved first. > -- > Michael >
