Docs 菜单

Docs 主页 → 开发应用程序 → MongoDB Manual

对分片集群进行故障排除

在此页面上

本页面介绍对分片集群部署进行故障排除的常见策略。

应用程序服务器或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 命令。

分片键

要对分片键进行故障排除，请参阅分片键故障排除。

集群可用性

要确保集群可用性：

  • 每个分片都应该是一个副本集，如果特定的 mongod 实例发生故障，副本集成员将选择其他成员作为主节点，并继续操作。但是，如果整个分片无法访问或由于某种原因而发生故障，则数据将不可用。

  • 分片键应支持 mongos 将大多数操作隔离到单个分片。如果操作可由单个分片处理，则单个分片的故障只会导致部分数据不可用。如果操作需要访问所有分片进行查询，则单个分片的故障将导致整个集群不可用。

配置数据库字符串错误

配置服务器必须部署为副本集。分片集群的 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 社区或MongoDB 支持部门解决此问题。

不一致的分片元数据

从 MongoDB 7.0 开始，可以使用 checkMetadataConsistency 命令检查分片元数据是否存在由于 MongoDB 早期版本中的错误而导致的不一致和损坏情况。

分片元数据不一致可能源于以下情况：

  • 从 MongoDB 5.0 之前版本升级的集群可能会损坏过去 DDL 操作的数据。

  • 手动干预，例如操作配置数据库或绕过 mongos 直接写入分片。

  • 维护操作，如升级或降级程序。

这些不一致可能导致查询结果不正确或数据丢失。

要检查分片元数据是否不一致，请运行 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 命令返回的不一致文档的信息，请参阅“不一致类型”。

← 分片集群中的操作限制
存储 →

在此页面上