Hi Stephen,
> On 10. Jul, 2020, at 17:45, Stephen Frost <sfrost@snowman.net> wrote:
>
> Sure, if you know exactly why the former primary failed and have
> confidence that nothing actually bad happened then pg_rewind can work
> (though it's still not what I'd generally recommend).
>
> If you don't actually know what happened to the former primary to cause
> it to fail then I definitely wouldn't use pg_rewind on it since it
> doesn't have any checks to make sure that the data is actually
> generally consistent. These days you could get a bit of a better
> feeling by running pg_checksums against the data dir, but that's not
> going to be as good as doing a pgbackrest delta restore when it comes to
> making sure that everything is valid.
we use Netapp plus continuous archiving. To protect agains block corruption, all our database clusters have been
createdwith initdb -k. So they should report block corruptions in the log.
The usual reason why a database cluster goes down is because the server is shut down which initiates a switchover and
isnot problematic. If the server goes down by a power outage, system crash or similar, then an automatic failover is
initiated,which, according to our experience, is also not problematic. Patroni seems to handle both situations well.
The worst case is, that both servers crash, which is pretty unlikely. So, the worst case is that we have to perform a
volumerestore with Netapp and replay the WAL files since that last snapshot. Should the replica database cluster be
damagedtoo, then we may need to reinit it with Patroni. This is acceptable even for large database clusters because
replicationruns fast. But the possibility is very, very small.
Why the -k option of initdb isn't default anyway, is beyond me. Yes, I know the argument about pg_upgrade messages,
whichpeople can't seem to cope with for some reason, but I can't see the reasoning. If I wanted to do a pg_upgrade from
anolder non-checksummed database cluster to a new major version with checksums, then I'd do initdb explicitly without
checksumsand perform the upgrade. Then I would enable checksums and that's it from then on. It's a one time only simple
commandfor each affected database cluster.
So, in my opinion, -k should be default and if one wanted to create a non-checksummed database cluster, it would have
tobe stated on the command line explicitly. This IMHO is a reasonable way to make people migrate to checksums over time
asdatabase clusters are migrated.
But then, that's only my opinion. There is no absolute truth.
Cheers,
Paul