this repo has no description
Another way
+34
+34
rfds/0005_generational_read_version.md
+34
rfds/0005_generational_read_version.md
···
77
77
At some point a Timekeeper role was added to the database to write the current versionstamp into the meta keyspace every 10 seconds.
78
78
Those keys are used as a reverse lookup table (real time -> versionstamp) internally within the database (IIRC for something backup-related).
79
79
This is, frankly, a pretty good hint that something has gone off the rails.
80
+
81
+
## Another way
82
+
83
+
I want Hobbes to have versions that line up with real (wall clock) time,
84
+
as this seems to be a useful property in practice.
85
+
Obviously the time will never be perfect (wall clocks can be wrong),
86
+
but Tigerbeetle in particular has shown that more can be done in this area.
87
+
88
+
Using wall clock time for versions is mostly trivial.
89
+
Like FDB, we already use wall clocks to match the *progression* of time (1 version = 1 microsecond),
90
+
so all that really needs to be done is to *start* a cluster at wall clock time (instead of zero)
91
+
and ensure strict monotonicity across generations (no regression if clocks go backwards) for safety.
92
+
93
+
And, of course, we need to avoid the fast-forward.
94
+
95
+
### Avoiding fast-forward
96
+
97
+
As discussed earlier,
98
+
there are two reasons for the fast-forward in FDB.
99
+
100
+
The first, with the Resolver, is easily fixed.
101
+
The new generation has a known start version,
102
+
and the Resolver (or the CommitBuffers) can reject transactions that started below that version.
103
+
This trivially ensures that transactions do not span recoveries.
104
+
105
+
The second reason, with the Storage servers, is trickier.
106
+
Storage servers do not participate directly in recovery,
107
+
and there is no guarantee that they'll find out about a new generation before a client attempts a read with a read version from it.
108
+
Since the generations' versions may overlap (because we don't fast-forward),
109
+
a client might read uncommitted data that was meant to be thrown away.
110
+
111
+
However, there is actually another simple solution:
112
+
we can accompany each read version with the generation of the transaction system that provided it.
113
+
If the Storage server receives a read from a newer generation, it can trivially reject that read.