[DOCS-7460] Comment on: "manual/tutorial/upgrade-config-servers-to-replica-set.txt" Created: 17/Mar/16  Updated: 30/Oct/23

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

Type: Bug Priority: Major - P3
Reporter: VictorGP Assignee: Kay Kim (Inactive)
Resolution: Won't Do Votes: 0
Labels: collector-298ba4e7
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Location: https://docs.mongodb.org/manual/tutorial/upgrade-config-servers-to-replica-set/
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36
Referrer: https://docs.mongodb.org/manual/release-notes/3.2-upgrade/
Screen Resolution: 1920 x 1080
repo: docs
source: tutorial/upgrade-config-servers-to-replica-set


Participants:
Days since reply: 1 year, 14 weeks, 2 days ago
Epic Link: DOCSP-1769

 Description   

I think this doc has something wrong.

In point 7 you shut down one of the remaining (second or third) config server, and it becomes read only.

Then in point 11, we restart the first config server and you say it is now writeable, but the config server that was shut down in point 7 is still down, so we are still in a 2 nodes config server, it shouldn't be writeable. Or maybe 1 node, because the first server is in state REMOVED within his replicaset.

The thing is that i don't see the goal of point 7, why do you need to take the second or the third config server down?



 Comments   
Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

Comment by VictorGP [ 17/Mar/16 ]

Ok, good.
I guess it needs a bit of clarification that in step 11 you have 2 set of config servers, CSRS and SCCC and that CSRS is the one that is writeable.

Thank you!

Comment by Kay Kim (Inactive) [ 17/Mar/16 ]

Yes. You're correct. In step 11, the csrs are in a state where you can update the meta data. To actually write to this CSRS, you would need to update the mongos to point to them. Kind of like if you were setting up a new sharded cluster and start up config servers but haven't set up the mongos, etc. The config servers are set up to be ready to accept writes.

If you don't update the mongos to point to the new CSRS, whether you take down the second config server or the third, since not all three config servers are available, the data in the SCCC config servers is read only.

Comment by VictorGP [ 17/Mar/16 ]

But, by step #11, mongos processes are still pointing to the old mirrored config servers, not the replicaset (that is in point 12)

Let's say in step 7 i took down the second server, by step 11 the first config server and the third will be up, the first one will be a replicaset now, but until mongos processes don't change, they won't connect to the replicaset but use the first and the third config servers, i assume.

Comment by Kay Kim (Inactive) [ 17/Mar/16 ]

Hi Victor –
at step #7 – config servers are still running in three mirrored SCCC mode. So, now, with a config server down, the metadata become read only.
but by step #11 – the config servers are those members in the replica set. So, if the member is in Removed state (i.e. it uses the mmapv1 storage engine), there should at this point be 3 other members in the replica set. If the first config server used the WT storage engine, then it won't be in a "removed" state and would be in a normal state.

Regards,

Kay Kim

Generated at Thu Feb 08 07:54:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.