[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: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 47 weeks, 2 days ago | ||||||||
| Description |
|
Per this comment on
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 ] |
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 |
| 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? |