On 9/18/19 8:58 PM, David Steele wrote:
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.
What's a timeline switchover?
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.
No cluster promotion even contemplated.
The point of the exercise would be to create an older copy of the cluster --
while the production cluster is still running, while production jobs are
still pumping data into the production database -- from before the time of
the data loss, and query it in an attempt to recover the records which were
deleted.
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,
--
Angular momentum makes the world go 'round.
