[SERVER-38617] Rollback via refetch can incorrectly timestamp index build writes Created: 13/Dec/18  Updated: 29/Oct/23  Resolved: 14/Dec/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.1.7

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

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2018-12-17
Participants:
Linked BF Score: 65

 Description   

Rollback via refetch goes through four steps before the node can return to the replica set as a functioning secondary:

  1. Enter rollback state
  2. Perform writes for rollback
  3. Apply oplog window determined via the node that was being fetched from
  4. Leave rollback state

All writes done while a node is in rollback state must be persisted before a node can persist a write that implies rollback has completed. This is the repl-storage rollback via refetch contract.

Rolling back a dropIndexes command will recreate the index via the secondary code path.

This will hit the code path that creates an IndexBuilder.

When the IndexBuilder completes an index, it has to decide how the catalog write will be timestamped, potentially timestamping the write itself via the time on the LogicalClock.

In the case of rollback, requiresGhostCommitTimestamp can return true. Additionally, there's no guarantee the LogicalClock time will be such that the write is persisted before the write that implies rollback is complete (the repl-storage rollback via refetch contract) . It's possible for the ready: true write to be too far in the future and not persisted on a restart. A restart would see an unfinished index and may drop it, which would result in an inconsistency with the rest of the replica set.



 Comments   
Comment by Githook User [ 14/Dec/18 ]

Author:

{'username': 'dgottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb'}

Message: SERVER-38617: Do not timestamp ghost writes during rollback via refetch.
Branch: master
https://github.com/mongodb/mongo/commit/45cdf964b9eae8f1f563ba3df4a0372fc341c26d

Comment by Daniel Gottlieb (Inactive) [ 13/Dec/18 ]

Note this is not a problem for 3.6/4.0 rollback via refetch. Those versions enable WT table logging for all tables, thus the ready: true write will be persisted across a restart despite an unexpected timestamp.

Generated at Thu Feb 08 04:49:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.