Details
Description
With the introduction of Config Servers as Replica Sets, shard hosts will checkpoint the latest config server opTime after each metadata operation they perform and if necessary on startup will contact the config server's primary in order to recover the minOpTime that they should be using.
This poses problems with restoring a host, which was previously backed up with this recovery information, because it will attempt to connect a potentially defunct config server.
For this reason, we need to either have a separate argument, which allows the recovery information to be ignored or we should start requiring --shardSvr to be specified for all shard servers.
Attachments
Issue Links
- depends on
-
SERVER-20943 Write procedures for restoring a CSRS sharded cluster
-
- Closed
-
- is documented by
-
-
- Closed
-
- is related to
-
SERVER-19934 Ill-timed crash at end of chunk migration can lead to lost writes when using replica sets as config servers
-
- Closed
-
-
-
- Closed
-
-
SERVER-20824 Test for sharding state recovery
-
- Closed
-