-
Type: Improvement
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Replication
-
Fully Compatible
We often need to do a sequence of requests against a node that may be invalidated if the node rolls back. We use the RBID for this and are planning on expanding its use in SERVER-27403. This gets simpler and requires fewer round-trips if each reply includes the RBID.
The main open question is whether to include the RBID from before the operation begins processing or after it completes and produces the rest of the results.
- Including the "before" rbid makes it possible to later say "these results haven't been rolled back if the rbid is the same."
- Including the "after" rbid makes it possible to say "if this rbid matches one you got before, you know nothing has rolled back yet"
- Including both lets you say both things
- We could also report one rbid and require that it not change while processing a single request. We would then error all requests when a rollback happens. This is related to
SERVER-27534.
We may want to include this in 3.6 even if we don't add any code that reads it. This would allow us to start using it in 3.8 without any mixed-version compatibility/fallback code.
- related to
-
SERVER-27403 Consider term and rbid when validating the proposed sync source
- Closed
-
SERVER-27534 All writing operations must fail if the term changes
- Closed
-
SERVER-27543 Create new metadata for oplog queries
- Closed