[SERVER-47812] Secondaries persist wildcard multikeypaths out of order Created: 27/Apr/20  Updated: 29/Oct/23  Resolved: 12/Sep/20

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: 4.2.0, 4.4.0-rc0
Fix Version/s: 4.8.0, 4.4.2, 4.2.12

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Bernard Gorman
Resolution: Fixed Votes: 0
Labels: qexec-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File server47812_repro.diff    
Issue Links:
Backports
Depends
Related
related to SERVER-56877 insert operations may fail to set ind... Closed
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
Participants:
Linked BF Score: 33

 Description   

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.



 Comments   
Comment by Githook User [ 20/Nov/20 ]

Author:

{'name': 'Bernard Gorman', 'email': 'bernard.gorman@gmail.com', 'username': 'gormanb'}

Message: SERVER-47812 Secondaries persist wildcard multikeypaths out of order

(cherry picked from commit bd320bc2d10cff75756a2c95986cc81ec8a5e7c7)
(cherry picked from commit 48089c01bcccc193b1d8dd3c50ae5cb3e072ebed)
Branch: v4.2
https://github.com/mongodb/mongo/commit/9870937b91b88348e619580f1050965b1006e33d

Comment by Githook User [ 19/Oct/20 ]

Author:

{'name': 'Bernard Gorman', 'email': 'bernard.gorman@gmail.com', 'username': 'gormanb'}

Message: SERVER-47812 Secondaries persist wildcard multikeypaths out of order

(cherry picked from commit bd320bc2d10cff75756a2c95986cc81ec8a5e7c7)
Branch: v4.4
https://github.com/mongodb/mongo/commit/48089c01bcccc193b1d8dd3c50ae5cb3e072ebed

Comment by Githook User [ 12/Sep/20 ]

Author:

{'name': 'Bernard Gorman', 'email': 'bernard.gorman@gmail.com', 'username': 'gormanb'}

Message: SERVER-47812 Secondaries persist wildcard multikeypaths out of order
Branch: master
https://github.com/mongodb/mongo/commit/bd320bc2d10cff75756a2c95986cc81ec8a5e7c7

Comment by Daniel Gottlieb (Inactive) [ 27/Aug/20 ]

judah.schvimer reminded me that we had tests which demonstrate bugs when multikey writes are incorrectly timestamped due to replication potentially processing entries out of order. Attached is a patch that fails most of the time (there's still some non-determinism) for wildcard indexes.

bernard.gorman, as per our conversations I wrote another test for multikey on index types that don't track paths (e.g: "2d"), but was able to observe the MultikeyPathTracker being modified and that side-effect correctly propagating into the special multikey write secondaries perform.

Generated at Thu Feb 08 05:15:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.