Project: MongoDB (App Definition and Development / Database)
File: README_startup_and_shutdown.md

The mongod intialization process is split into three phases. The first phase runs on startup and initializes the set of stateless components based on the cluster role. The second phase then initializes additional components that must be initialized with state read from the config server. The third phase is run on the and starts services that only run on primaries. On a shard server, the `CollectionShardingState` factory is set to an instance of the `CollectionShardingStateFactoryShard` implementation. The component lives on the service context. The sharding and registered with the service context. The `MigrationChunkClonerSourceOpObserver` class forwards operations during migration to the chunk cloner. The `ShardServerOpObserver` class is used to handle the majority of sharding related events. These include loading the shard identity document when it is inserted and performing range deletions when they are marked as ready. The if it already exists on startup. For shards, the shard identity document specifies the config server connection string. If the shard does not have a shardIdentity document, it has not been added to a cluster yet, and the "Phase 2" initialization happens when the shard receives a shardIdentity document as part of addShard. If the shard identity document was found, then the from its fields. The global sharding state is set on the Grid. The Grid contains the sharding context for a running server. It exists both on mongod and mongos because the Grid holds all the components needed for routing, and both mongos and shard servers can act as routers. `KeysCollectionManager` is set on the `LogicalTimeValidator`. The `ShardingReplicaSetChangeListener` is instantiated and set on the `ReplicaSetMonitor`. The remaining sharding components are before the Grid is marked as initialized. Shard servers that only run on primaries. The sharding and registered with the service context. The config server registers the OpObserverImpl and ConfigServerOpObserver observers. The global sharding state is set on the Grid. The Grid contains the sharding context for a running

The config server does not need to be provided with the config server connection string explicitly as it is part of its local state. Config servers that only run on primaries. The global sharding state is set on the Grid. The Grid contains the sharding context for a running server. Mongos is provided with the config server connection string as a startup parameter. Function to . Function to on shard server. Hook for sharding . If the mongod server is primary, it will . Mongod and mongos then run their respective shutdown tasks which cleanup the remaining sharding components. for mongod. for mongos. mongos enters quiesce mode prior to shutdown, to allow short-running operations to finish. During this time, new and existing operations are allowed to run, but `isMaster`/`hello` requests return a `ShutdownInProgress` error, to indicate that clients should start routing operations to other nodes. Entering quiesce mode is considered a significant topology change in the streaming `hello` protocol, so mongos tracks a `TopologyVersion`, which it increments on entering quiesce mode, prompting it to respond to all waiting hello requests. In order to preserve backwards compatibility with old drivers, mongos currently supports both the [`isMaster`] command and the [`hello`] command. New drivers and 5.0+ versions of the server will support `hello`. When connecting to a sharded cluster via mongos, a new driver will send "helloOk: true" as a part of the initial handshake. If mongos supports hello, it will respond with "helloOk: true" as well. This way, new drivers know that they're communicating with a version of the mongos that supports `hello` and can start sending `hello` instead of `isMaster` on this connection. If mongos does not support `hello`, the `helloOk` flag is ignored. A new driver will subsequently not see "helloOk: true" in the response and must continue to send `isMaster` on this connection. Old drivers will not specify this flag at all, so the behavior remains the same. When mongos establishes outgoing connections to mongod nodes in the cluster, it always uses `hello` rather than `isMaster`. for mongos. for mongos.