对分片集群进行故障排除
在此页面上
本页介绍对分片集群部署进行故障排除的常用策略。
开始之前
从MongoDB 8.0开始，您可以使用directShardOperations角色执行需要直接对分片执行命令的分片操作。
警告
使用directShardOperations角色运行命令可能会导致集群停止正常工作，并可能导致数据损坏。 仅将directShardOperations角色用于维护目的或在MongoDB支持的指导下使用。 执行完维护操作后，请停止使用directShardOperations角色。
应用程序服务器或 mongos 实例变得不可用
如果每个应用程序服务器都有自己的 mongos 实例，则其他应用程序服务器可以继续访问数据库。此外，mongos 实例不会保持持久状态，它们可以重启并变得不可用，而不会丢失任何状态或数据。当 mongos 实例启动时，它会检索配置数据库的副本，并开始路由查询。
分片副本集中单个成员变得不可用
副本集为分片提供高可用性。如果不可用的 mongod 是主节点，则副本集将选举新的主节点。如果不可用的 mongod 是从节点，且与主节点断开连接，则从节点将继续保存所有数据。在由三个成员组成的副本集中，即使其中一个成员发生灾难性故障，其他两个成员也拥有完整的数据副本。[1]
始终调查可用性中断和故障。如果系统无法恢复，应尽快替换系统并创建副本集的新成员，以替代损失的冗余。
| [1] | 如果不可用的从节点变得可用，同时仍然具有当前的 oplog 条目，则可以通过正常的复制进程同步到最新状态；否则，它必须执行初始同步。 |
分片所有成员都变得不可用
在分片集群中，mongod 和 mongos 实例监控分片集群中的副本集（例如分片副本集、配置服务器副本集）。
如果副本集分片的所有成员都不可用，则该分片中保存的所有数据都不可用。但是，所有其他分片上的数据仍然可用，并且可由其他分片读取和写入数据。但是，应用程序必须能够处理部分结果，您应该调查中断的原因，并尝试尽快恢复分片。
配置服务器副本集成员不可用
副本集可为配置服务器提供高可用性。如果不可用的配置服务器是主节点，那么副本集将选举出新的主节点。
如果副本集配置服务器丢失其主节点并且无法选择主节点，则集群的元数据将变为只读。您仍然可以从分片读取和写入数据，但在主节点可用之前，不会发生数据段迁移或数据段分割。
注意
将副本集成员分布在两个数据中心比分布在一个数据中心更有优势。分布在两个数据中心时，
如果其中一个数据中心发生故障，数据仍可供读取，分布在单个数据中心则无法实现此功能。
如果具有少数成员的数据中心出现故障，副本集仍然可以支持写入操作和读取操作。
但是，如果具有大多数成员的数据中心出现故障，副本集将变为只读。
如有可能，请将成员分布在至少三个数据中心。对于配置服务器副本集 (CSRS)，最佳实践是分布在三个数据中心（也可根据成员数量来增加数据中心数量）。如果使用第三个数据中心成本过高，一种可行的分布方法是在两个数据中心均匀分配数据承载成员，并将剩余成员存储在云中（如果公司政策允许）。
注意
在您首次启动分片集群时，所有配置服务器必须正在运行且可用。
游标因配置数据过时而失败
当一个或多个 mongos 实例尚未更新其配置数据库中集群元数据的缓存时，查询会返回以下警告：
could not initialize cursor across all shards because : stale config detected
该警告不应传播回应用程序。该警告将重复出现，直到所有 mongos 实例刷新缓存。要强制实例刷新缓存，请运行 flushRouterConfig 命令。
分片键
要对分片键进行故障排除，请参阅分片键故障排除。
集群可用性
要确保集群可用性：
Config Database String Error
配置服务器必须部署为副本集。分片集群的 mongos 实例必须指定相同的配置服务器副本集名称，但可指定副本集不同节点的主机名和端口。
早期版本的 MongoDB 分片集群使用三个镜像 mongod 实例作为配置服务器的拓扑结构，因此分片集群的 mongos 实例必须指定相同的 configDB 字符串。
移动配置服务器时避免停机
使用 CNAME 向集群标识您的配置服务器，以便在不停机的情况下对您的配置服务器进行重命名和重新编号。
moveChunk commit failed 错误
数据段迁移结束时，分片必须连接到配置数据库以更新集群元数据中的数据段记录。如果分片无法连接到配置数据库，MongoDB 会报告以下错误：
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"
发生这种情况时，分片副本集的主节点将终止，以保护数据一致性。如果从节点可以访问配置数据库，则在选举后，可再次访问分片数据。
用户需要独立解决数据块迁移失败的问题。如果您遇到此问题，请咨询 MongoDB Community或 MongoDB 支持部门，以解决此问题。
不一致的分片元数据
从 MongoDB 7.0 开始，可以使用 checkMetadataConsistency 命令检查分片元数据是否存在由于 MongoDB 早期版本中的错误而导致的不一致和损坏情况。
分片元数据不一致可能源于以下情况：
这些不一致可能导致查询结果不正确或数据丢失。
要检查分片元数据是否不一致，请运行 checkMetadataConsistency 命令：
db.runCommand( { checkMetadataConsistency: 1 } )
{ cursor: { id: Long("0"), ns: "test.$cmd.aggregate", firstBatch: [ { type: "MisplacedCollection", description: "Unsharded collection found on shard different from database primary shard", details: { namespace: "test.authors", shard: "shard02", localUUID: new UUID("1ad56770-61e2-48e9-83c6-8ecefe73cfc4") } } ], }, ok: 1 }
checkMetadataConsistency 命令返回的文档表明 MongoDB 在集群的分片元数据中发现的不一致情况。
有关 checkMetadataConsistency 命令返回的不一致文档的信息，请参阅“不一致类型”。