Is your feature request related to a problem? Please describe.
CRDB needs to log the original and final zone configuration changes when such are made. Currently there is no way to tell what was the original/previous zone configuration if it was changed. Only the final config is logged.
This is a problem mostly when the replication factor changes (e.g. from 3 to 5) and the console starts reporting under replicated ranges.
Describe the solution you'd like
CRDB needs to write both the original and the final zone configuration in the events log or audit log or somewhere else.
Describe alternatives you've considered
Currently the only alternative is to run something like this and go back in time (if the GC hasn't ran yet):
SELECT id, crdb_internal.pb_to_json('cockroach.config.zonepb.ZoneConfig', config) FROM system.zones AS OF SYSTEM TIME '<insert some time>;
Additional context
Without this it is harder to troubleshoot under replicated ranges when replication factor has been increased.
Is your feature request related to a problem? Please describe. CRDB needs to log the original and final zone configuration changes when such are made. Currently there is no way to tell what was the original/previous zone configuration if it was changed. Only the final config is logged. This is a problem mostly when the replication factor changes (e.g. from 3 to 5) and the console starts reporting under replicated ranges.
Describe the solution you'd like CRDB needs to write both the original and the final zone configuration in the events log or audit log or somewhere else.
Describe alternatives you've considered Currently the only alternative is to run something like this and go back in time (if the GC hasn't ran yet):
Additional context Without this it is harder to troubleshoot under replicated ranges when replication factor has been increased.
Jira issue: CRDB-40305
Epic CRDB-31473