[DOCS-12213] Clarify when and how to put replica set members into standalone mode for maintenance Created: 19/Nov/18  Updated: 30/Oct/23  Resolved: 13/Mar/23

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Task Priority: Major - P3
Reporter: Andy Schwerin Assignee: Unassigned
Resolution: Won't Do Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-38174 Starting replica set member standalon... Closed
Participants:
Days since reply: 47 weeks, 2 days ago

 Description   

Per this comment on SERVER-38174, we should update the documentation around maintenance of replica sets to clarify a few points.

  1. Beginning in MongoDB 4.0, when restarting members of replica sets in standalone mode (without the --replset argument),
    1. The node will not provide read access to the most current data it possesses, but only to data that is no more recent that the majority commit point, unless
    2. the node is started with the recoverFromOplogAsStandalone flag, in which case the node will present all data it has accepted, but will not accept write operations.
  2. In all versions of MongoDB,
    1. performing write operations on replica set members running in standalone mode risks data corruption
    2. and only the following operations are endorsed, though even they may lead to corruption if not used carefully:
      1. Building indexes, with caveats around the danger of building unique indexes in this manner
      2. Manipulating the contents of the local database, with caveats around the risks of updating collections involved in the replication process

Further, we should review any documentation we have that involves doing maintenance on replica set members in standalone mode to ensure they are correct, or can be safely performed.



 Comments   
Comment by Ashley Brown [ 13/Mar/23 ]

Hi schwerin@mongodb.com, we're closing this ticket because (I believe) it was determined we shouldn't document how to convert a replica set to a standalone and customers who want to do this should connect with TS. If you believe this is an error, please reopen the ticketĀ  and we'll take a look. Thanks!

Comment by Bruce Lucas (Inactive) [ 19/Nov/18 ]

You mean the data 3.6 would have returned

Yes, sorry - corrected.

Comment by Andy Schwerin [ 19/Nov/18 ]

You mean the data 3.6 would have returned, right, bruce.lucas? I thought this change stemmed from the recover-to-timestamp work from 4.0.

Comment by Bruce Lucas (Inactive) [ 19/Nov/18 ]

I'm not sure if we do either. But the thing that I think is important to call out is that it may not return data that was majority committed, even if that node participated in the majority commit (e.g. was primary) or had no lag. Secondarily, it is useful to point out that the data returned may be considerably less current than the data that 3.4 3.6 would have returned.

Comment by Andy Schwerin [ 19/Nov/18 ]

It will return exactly the data in the last checkpoint on the node. I wasn't sure if we document the concept of checkpoints.

Comment by Bruce Lucas (Inactive) [ 19/Nov/18 ]

schwerin, shouldn't "The node will not provide read access to the most current data it possesses, but only to data that is no more recent that the majority commit point" be "... no more recent than the last successful checkpoint on the node", which, in the case of a crash, may be (considerably) older than the majority commit point?

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