-
Type:
Bug
-
Status: Closed
-
Priority:
Major - P3
-
Resolution: Fixed
-
Affects Version/s: 4.2.0, 4.4.0-rc0
-
Component/s: Replication, Storage
-
Labels:
-
Backwards Compatibility:Fully Compatible
-
Operating System:ALL
-
Backport Requested:v4.4, v4.2
-
Sprint:Query 2020-08-24, Query 2020-09-07, Query 2020-09-21
-
Linked BF Score:33
Because secondaries apply operations out of order, the following scenario can play out in the absence of special logic:
{op: "i", o: {_id: "A", a: [1,2]}, ts: Timestamp(1, 1)}}
|
{op: "i", o: {_id: "B", a: [1,2]}, ts: Timestamp(1, 2)}}
|
|
| Applier 1 | Applier 2 | Reader |
|
|----------------------+------------------------------+-------------------------------------------|
|
| Begin Txn | | |
|
| Write B | | |
|
| Update Indexes | | |
|
| Update Multikeypaths | | |
|
| TimestampTxn (1, 2) | | |
|
| Commit | | |
|
| | Begin Txn | |
|
| | Write A | |
|
| | Update Indexes | |
|
| | (No Multikeypaths to update) | |
|
| | TimestampTxn (1, 1) | |
|
| | Commit | |
|
| | | BeginTxn |
|
| | | ReadTimestamp (1,1) |
|
| | | Sees A |
|
| | | Does not see corresponding multikey paths |
|
See this comment for persisting classical index multikey paths.