On 9/18/19 9:40 PM, Ron wrote:
>
> I'm concerned with one pgbackrest process stepping over another one and
> the restore (or the "pg_ctl start" recovery phase) accidentally
> corrupting the production database by writing WAL files to the original
> cluster.
This is not an issue unless you seriously game the system. When a
cluster is promoted it selects a new timeline and all WAL will be
archived to the repo on that new timeline. It's possible to promote a
cluster without a timeline switch by tricking it but this is obviously a
bad idea.
So, if you promote the new cluster and forget to disable archive_command
there will be no conflict because the clusters will be generating WAL on
separate timelines.
In the case of a future failover a higher timeline will be selected so
there still won't be a conflict.
Unfortunately, that dead WAL from the rogue cluster will persist in the
repo until an PostgreSQL upgrade because expire doesn't know when it can
be removed since it has no context. We're not quite sure how to handle
this but it seems a relatively minor issue, at least as far as
consistency is concerned.
If you do have a split-brain situation where two primaries are archiving
on the same timeline then first-in wins. WAL from the losing primary
will be rejected.
Regards,
--
-David
david@pgmasters.net
