version_stamps guaranteed to be
unique and monotonic for the life of a FDB cluster? Are there scenarios when version_stamps may be reset to value lesser than one already generated?
In this discussion Christophe mentioned that in case a new cluster is being restored from a backup, the version_stamps may be reset to 0 (or more generally to some start value that is
<= to a value already generated earlier in the fdb cluster from where the backup was taken).
By the way: there is no guarantee that version stamps will always go up: if you are restoring from a backup after completely reinstalling a new cluster, it may be possible that the read version starts again from 0… The conditions to make this happen may be improbable, but not impossible!
Is there a way to avoid this? Maybe by including in backup some meta-data that tells the FDB cluster to start version_stamp generation from a given value onwards? Or some other approach that clients can themselves take to get around this? Any pointers will be very helpful.
I was thinking of using version_stamps for multiple purposes:
- as a reference key between two key-values (e.g. data_row, and corresponding index_row).
- as a prefix key in a
logindex so that I can “tail” the index from a given bookmark (version_stamp), and cycle…
But if I cannot guarantee the uniqueness and monotonicity of these then it becomes difficult to use it for above use-cases.