对分片集群进行故障排除
在此页面上
本页介绍对分片集群部署进行故障排除的常用策略。
应用程序服务器或 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
命令返回的不一致文档的信息,请参阅“不一致类型”。