|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Keiko Oda <keiko713(at)gmail(dot)com>|
|Subject:||Re: Trigger file behavior with the standby|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, Mar 28, 2018 at 12:23:31PM -0700, Keiko Oda wrote:
> 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?
Per the code and the documentation, the current behavior is clearly
intentional. If you think about it, it can be relatively important
especially in the case of a base backup taken without WAL segments in
pg_wal while relying on a separate archive: this gives more guarantees
that the consistent point will be reached. That also covers a bit what
people can look for in some cases with recovery_target = 'immediate'.
You could indeed tweak the restore command. If a failure happens while
attempting to fetch a WAL segment, then the recovery would immediately
stop. If you try to trigger a promotion without reaching a consistency
point, then you would get a complain from the startup process. There
are some safeguards for this purpose.
Please don't take me wrong. There is room for a feature which does more
efficiently what you are looking for, but that would be a separate
(Sakura season here by the way, they are blooming this week)
|Next Message||Michael Paquier||2018-03-29 00:05:27||Re: [bug fix] pg_rewind creates corrupt WAL files, and the standby cannot catch up the primary|
|Previous Message||Michael Paquier||2018-03-28 23:55:39||Re: Using base backup exclusion filters to reduce data transferred with pg_rewind|