-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 4.2.0, 4.4.0-rc0
-
Component/s: Replication, Storage
-
Fully Compatible
-
ALL
-
v4.4, v4.2
-
Query 2020-08-24, Query 2020-09-07, Query 2020-09-21
-
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.
- related to
-
SERVER-56877 insert operations may fail to set index to multikey after aborted multikey catalog update
- Closed