-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
Repl 2018-03-26
With the recover to timestamp project now when you restart a replica set node as a standalone, the data will be at the checkpoint timestamp even though the oplog may contain entries past that time that have 'logically' been applied to this node (and would get applied at startup before accepting connections if the node was restarted as a replica set member again).
We already log the following startupWarning when a standalone is brought up that detects a replica set configuration:
2017-08-01T14:47:29.115-0400 I STORAGE [initandlisten] ** WARNING: mongod started without --replSet yet 1 documents are present in local.system.replset
2017-08-01T14:47:29.115-0400 I STORAGE [initandlisten] ** Restart with --replSet unless you are doing maintenance and no other clients are connected.
2017-08-01T14:47:29.115-0400 I STORAGE [initandlisten] ** The TTL collection monitor will not start because of this.
2017-08-01T14:47:29.115-0400 I STORAGE [initandlisten] **
We should amend that message to also say that the data may look inconsistent with the oplog. Perhaps something like adding the line "Database contents may appear inconsistent with the contents of the oplog and may appear to not contain writes that were visible when this node was running as part of a replica set." between the first and second lines of the existing message.
- depends on
-
SERVER-33292 Have storage dictate where replication recovery should begin playing oplog from
- Closed
- is related to
-
SERVER-33349 Add command to get stable checkpoint timestamp
- Closed
- related to
-
SERVER-33986 Log stable checkpoint when restarting as a standalone
- Closed