Details
-
Task
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
None
-
None
-
true
Description
Documentation Request Summary:
Per the code review, we should revisit our maintenance mode documentation and mention what operations are safe to perform when bringing up a repl set member as a standalone.
Scope of changes:
/tutorial/perform-maintence-on-replica-set-members
Impact to other docs outside of this product:
none
MVP:
Resources:
Engineering Ticket Description:
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.
Attachments
Issue Links
- documents
-
SERVER-30464 Edit startup warning when running replset member as standalone to mention that data may look inconsistent
-
- Closed
-