On 9/18/19 8:31 PM, David Steele wrote:
On 9/18/19 6:59 PM, Ron wrote:
Scenario: there's data corruption on production server, so we need to do
a PITR restore from "a few days ago" of the cluster holding the prod
databases to a second cluster on that same VM in order to try and find
the missing data and load it back into the prod cluster.
Other than putting a high I/O load on the LUN where repo-path is located
(from both writing WALs to it and reading the backed up files), will
there be any problems when "pg_ctl start" processes recovery.conf and
applies the WAL files to the new cluster while the prod cluster is
writing new WAL files.
Does my question make sense?
It does, but the answer lies outside of pgBackRest. "Can the repo
storage handle the load of archive-push and archive-get at the same
time" is really a question of storage and network throughput.
That's outside my control and will "just" slow things down.
pgBackRest compresses everything by default which goes a long way
towards increasing throughput, but ultimately we don't control the
bandwidth.
Having said that, if the storage and network throughput are sufficient,
restoring and recovering a standby using pgBackRest will not impact the
primary as a direct pg_basebackup will.
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.
--
Angular momentum makes the world go 'round.
