Am Mittwoch, den 13.03.2019, 12:43 +0100 schrieb Magnus Hagander: > I think this is dangerous enough that it needs to be enforced and not > documented.
Changing the cluster ID might have some other side-effects, I think there are several cloud-native 3rd party solutions that use the cluster ID as some kind of unique identifier for an instance. It might not be an issue in practise, but then again, it might break other stuff down the road.
Well, whatever we do they have to update, right? If we're not changing it, then we're basically saying that it's (systemid, checksums) that is the identifier of the cluster, not just systemid. They'd have to go around and check each node individually for the configuration and not just use systemid anyway, so what's the actual win?
Another possibility would be to extend the replication protocol's IDENTIFY_SYSTEM command to also report the checksum version so that the standby can check against the local control file on startup. But I am not sure we can easily extend IDENTIFY_SYSTEM this way nor whether we should for this rather corner-casey thing?
We could, but is it really a win in those scenarios? Vs just making the systemid different? With systemid being different it's obvious that something needs to be done. If it's not then at the best, if we check it in the standby startup, the standby won't start. But people can still end up with things like unusuable/corrupt backups for example.
