[DOCS-15066] Update page for Convert a Replica Set to a Sharded Cluster to mention application downtime Created: 25/Jan/22  Updated: 30/Oct/23  Due: 11/Feb/22  Resolved: 09/Feb/22

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

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Joseph Dougherty
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-60466 Support drivers gossiping signed $clu... Closed
Participants:
Days since reply: 2 years ago
Epic Link: DOCSP-11701

 Description   

The Convert a Replica Set to a Sharded Cluster flow has users take ordinary replica set members out of rotation and start them up again with --shardsvr. The user's application remains directly connected to the replica set during this step. A driver would have previously received signed $clusterTimes from the ordinary replica set members and will therefore attempt to gossip them back to the members after they've been started up again with --shardsvr. As noted in SERVER-60466, the driver sending these signed $clusterTimes will result in application errors during the conversion process.

  • From the time starting after the replica set member are restarted with --shardsvr and until the operator runs the addShard command, an application which had been connected beforehand to the replica set beforehand will continuously error with CannotVerifyAndSignLogicalTime.
  • Restarting the application after restarting all of the replica set members with --shardsvr is a method to reset the driver's notion of the signed $clusterTime and restore availability.
  • It isn't possible to avoid downtime entirely. Either the application will error from CannotVerifyAndSignLogicalTime or will be unavailable from restarting the application servers.
  • We should probably reorder the steps so the Deploy Config Server Replica Set and mongos section happens before the replica sets members are restarted with --shardsvr. This way the addShard command can be run more promptly.


 Comments   
Comment by Githook User [ 09/Feb/22 ]

Author:

{'name': 'jmd-mongo', 'email': '73852296+jmd-mongo@users.noreply.github.com', 'username': 'jmd-mongo'}

Message: DOCS-15066 refactor Convert Replica Set to Replicated Shard Cluster (#479) (#583)

  • refactor Convert Replica Set to Replicated Shard Cluster
  • review feedback
  • removes Downtime sub-heading
  • review feedback
  • fixes typo
  • updates warning
  • let users know they may need to restart apps connected to secondaries
  • updates primary warning
Comment by Githook User [ 09/Feb/22 ]

Author:

{'name': 'jmd-mongo', 'email': '73852296+jmd-mongo@users.noreply.github.com', 'username': 'jmd-mongo'}

Message: DOCS-15066 refactor Convert Replica Set to Replicated Shard Cluster (#479) (#581)

  • refactor Convert Replica Set to Replicated Shard Cluster
  • review feedback
  • removes Downtime sub-heading
  • review feedback
  • fixes typo
  • updates warning
  • let users know they may need to restart apps connected to secondaries
  • updates primary warning
Comment by Githook User [ 09/Feb/22 ]

Author:

{'name': 'jmd-mongo', 'email': '73852296+jmd-mongo@users.noreply.github.com', 'username': 'jmd-mongo'}

Message: DOCS-15066 refactor Convert Replica Set to Replicated Shard Cluster (#479)

  • refactor Convert Replica Set to Replicated Shard Cluster
  • review feedback
  • removes Downtime sub-heading
  • review feedback
  • fixes typo
  • updates warning
  • let users know they may need to restart apps connected to secondaries
  • updates primary warning
Generated at Thu Feb 08 08:11:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.