对副本集进行故障排除

MongoDB 中文手册

参考 > 复写 > 复制参考 > 对副本集进行故障排除

在本页面

检查副本集状态
检查复制延迟
Oplog条目的应用缓慢
测试所有成员之间的连接
重新启动多个辅助节点时的套接字异常
检查操作日志的大小
Oplog输入时间戳错误

本节介绍了对副本集部署进行故障排除的常见策略。

检查副本集状态¶

要显示副本集的当前状态和每个成员的当前状态，请rs.status()在mongo 连接到副本集的primary的外壳程序中运行该方法。有关显示的信息的说明rs.status()，请参见 replSetGetStatus。

注意

该rs.status()方法是运行replSetGetStatus数据库命令的包装器。

检查复制滞后¶

复制滞后是在主操作上的操作与该操作从操作日志到辅助操作之间的延迟。复制滞后可能是一个重要问题，并且可能严重影响MongoDB 副本集的部署。过多的复制滞后使“滞后”成员不具备迅速成为主要成员的资格，并增加了分布式读取操作不一致的可能性。

要检查当前复制滞后时间：

在mongo连接到主服务器的外壳程序中，调用该 rs.printSlaveReplicationInfo()方法。

返回syncedTo每个成员的值，该值显示最后一个操作日志条目写入辅助节点的时间，如以下示例所示：
复制
```
source: m1.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
source: m2.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
```
甲延迟构件可能显示为0 背后的主要秒时在初级非活动时间比更大members[n].slaveDelay 值。

注意

该rs.status()方法是replSetGetStatus数据库命令的包装。
通过检查Cloud Manager 和Ops Manager中可用的“ 复制滞后”图中的非零或增加oplog时间值来监视复制速率。

复制滞后原因¶

复制延迟的可能原因包括：

网络延迟

检查您的集合成员之间的网络路由，以确保没有数据包丢失或网络路由问题。

使用包括在内的工具ping来测试集合成员之间的等待时间，并traceroute公开数据包网络端点的路由。
磁盘吞吐量

如果辅助节点上的文件系统和磁盘设备无法像主节点一样快地将数据刷新到磁盘，则辅助节点将很难保持状态。与磁盘相关的问题在多租户系统（包括虚拟实例）上非常普遍，如果系统通过IP网络访问磁盘设备（与Amazon EBS系统一样），则可能是暂时的。

使用系统级工具评估磁盘状态，包括 iostat或vmstat。
并发

在某些情况下，在主数据库上长时间运行的操作可能会阻止在辅助数据库上进行复制。为了获得最佳结果，请将写关注配置为要求确认复制到辅助副本。如果复制无法跟上写负载，这可以防止写操作返回。

您还可以使用数据库探查器来查看是否存在与滞后发生率相对应的慢查询或长时间运行的操作。
适当的写关注

如果您要执行大量数据提取或批量加载操作，这需要对主数据库进行大量写入，尤其是使用，则辅助数据库将无法足够快地读取操作日志以跟上更改。unacknowledged write concern

为避免这种情况，每隔100、1,000或另一个间隔后，请求写确认写入问题就为次要节点提供了跟上主要节点的机会。

有关更多信息，请参见：

流量控制¶

从MongoDB 4.2开始，管理员可以限制主数据库应用其写入的速率，以将延迟保持在可配置的最大值以下。majority committedflowControlTargetLagSeconds

默认情况下，流量控制为enabled。

注意

为了启用流控制，副本集/分片集群必须具有：featureCompatibilityVersion（FCV） of 4.2并读取关注。也就是说，如果未启用FCV 或禁用了多数读功能，则启用的流控制无效。majority enabled4.2

启用流量控制后，随着滞后时间逐渐接近 flowControlTargetLagSeconds，主锁上的写操作必须先获得票证，然后才能锁定应用写操作。通过限制每秒发出的票证数量，流控制机制尝试将滞后保持在目标以下。

有关流控制统计信息，请参阅：

Oplog条目的应用速度很慢¶

从版本4.2（也从版本4.0.6开始可用）开始，副本集的辅助成员现在记录的oplog条目所花费的时间比慢操作阈值要长。这些缓慢的oplog消息会在组件下的文本中记录为次要日志。这些慢操作日志条目仅取决于慢操作阈值。它们不依赖于日志级别（在系统级别或组件级别），配置级别或运行缓慢的采样率。探查器不会捕获缓慢的操作日志条目。diagnostic logREPLapplied op: <oplog entry> took <num>ms

测试所有成员之间的连接¶

副本集的所有成员必须能够连接到集合的每个其他成员以支持复制。始终验证两个“方向”上的连接。网络拓扑和防火墙配置可能会阻止正常的连接和所需的连接，从而阻止复制。

从MongoDB 3.6，MongoDB二进制文件mongod和开始 mongos，默认情况下绑定到localhost。如果为二进制net.ipv6文件设置了配置文件设置或--ipv6命令行选项，则二进制文件还会绑定到本地IPv6地址。

以前，从MongoDB 2.6开始，默认情况下，只有正式的MongoDB RPM（Red Hat，CentOS，Fedora Linux和衍生产品）和DEB（Debian，Ubuntu和衍生产品）的二进制文件才绑定到localhost。

当仅绑定到本地主机时，这些MongoDB 3.6二进制文件只能接受来自mongo在同一台计算机上运行的客户端（包括Shell，副本集中部署的其他成员和分片群集）中的连接。远程客户端无法连接到仅绑定到本地主机的二进制文件。

要覆盖并绑定到其他IP地址，可以使用 net.bindIp配置文件设置或 --bind_ip命令行选项来指定主机名或IP地址的列表。

警告

在绑定到非本地主机（例如，可公共访问）的IP地址之前，请确保已保护群集免受未经授权的访问。有关安全建议的完整列表，请参阅“ 安全清单”。至少应考虑启用身份验证并强化网络基础架构。

例如，以下mongod实例绑定到localhost和My-Example-Associated-Hostname与ip地址关联的主机名198.51.100.1：

复制

mongod --bind_ip localhost,My-Example-Associated-Hostname

为了连接到该实例，远程客户端必须指定主机名或其关联的IP地址198.51.100.1：

复制

mongo --host My-Example-Associated-Hostname

mongo --host 198.51.100.1

考虑以下双向网络测试示例：

例

给定一个副本集，其中三个成员在三个不同的主机上运行：

m1.example.net
m2.example.net
m3.example.net

这三个都使用默认端口27017。

m1.example.net使用以下操作集测试到其他主机的连接m1.example.net：

复制

mongo --host m2.example.net --port 27017

mongo --host m3.example.net --port 27017

使用从中m2.example.net设置的以下操作来测试与其他两台主机的连接m2.example.net：
复制
```
mongo --host m1.example.net --port 27017

mongo --host m3.example.net --port 27017
```
现在，您已经测试之间的连接 m2.example.net，并m1.example.net在两个方向上。
通过从m3.example.net主机设置以下操作，测试到其他两个主机的连接m3.example.net：
复制
```
mongo --host m1.example.net --port 27017

mongo --host m2.example.net --port 27017
```

如果任何方向的任何连接失败，请检查网络和防火墙配置，然后重新配置环境以允许这些连接。

重新启动多个辅助节点时的套接字异常

重新引导副本集的成员时，请确保该副本集能够在维护期间选择主副本集。这意味着要确保大多数集合members[n].votes可用。

当集合的活动成员不再能形成多数时，该集合的主要成员将退而成为次要成员。从MongoDB 4.2开始，当主数据库降级时，它将不再关闭所有客户端连接。在MongoDB 4.0和更早版本中，当主数据库降级时，它将关闭所有客户端连接。

在成员选择新的主副本之前，客户端无法写入副本集。

例

给定一个三成员副本集，其中每个成员都有一票，如果至少有两个成员可以相互连接，则该集合可以选举主要成员。如果您立即重新引导两个辅助节点，则主要节点会降级并成为辅助节点。在至少另一个辅助节点变为可用（即，至少一个重新启动的辅助节点也变为可用）之前，该集合没有主要节点，也无法选择新的主要节点。

有关投票的更多信息，请参阅副本集选举。有关连接错误的相关信息，请参阅TCP保持活动时间是否影响MongoDB部署？。

检查Oplog的大小¶

较大的oplog可以使副本集对延迟的容忍度更高，并使集合更具弹性。

要检查给定副本集成员的操作日志的大小，请在mongo外壳中连接到该成员并运行该 rs.printReplicationInfo()方法。

输出显示操作日志的大小和操作日志中包含的操作的日期范围。在以下示例中，操作日志大约为10 MB，并且能够容纳大约26小时（94400秒）的操作：

复制

configured oplog size:   10.10546875MB
log length start to end: 94400 (26.22hrs)
oplog first event time:  Mon Mar 19 2012 13:50:38 GMT-0400 (EDT)
oplog last event time:   Wed Oct 03 2012 14:59:10 GMT-0400 (EDT)
now:                     Wed Oct 03 2012 15:00:21 GMT-0400 (EDT)

操作日志应足够长，以使所有事务在您希望辅助服务器上拥有最长的停机时间。[1]最低限度，一个oplog应该至少能够保存24小时的运营；但是，许多用户更喜欢72小时甚至一周的工作时间。

有关oplog大小如何影响操作的更多信息，请参见：

注意

通常，您希望所有成员的oplog大小相同。如果您调整操作日志的大小，请在所有成员上调整它的大小。

要更改操作日志的大小，请参阅“ 更改操作日志的大小” 教程。

[1]	从MongoDB 4.0开始，操作日志可以超过其配置的大小限制，以避免删除。`majority commit point`

Oplog输入时间戳错误¶

考虑mongod输出和日志中的以下错误：

复制

replSet error fatal couldn't query the local local.oplog.rs collection.  Terminating mongod after 30 seconds.
<timestamp> [rsStart] bad replSet oplog entry?

通常，ts最后一个oplog条目中的字段中输入的值输入错误会导致此错误。正确的数据类型是时间戳。

ts使用以下两个查询对oplog集合检查值的类型：

复制

db = db.getSiblingDB("local")
db.oplog.rs.find().sort({$natural:-1}).limit(1)
db.oplog.rs.find({ts:{$type:17}}).sort({$natural:-1}).limit(1)

第一个查询返回操作日志中的最后一个文档，第二个查询返回操作日志中的最后一个文档，其中ts值是时间戳。该$type运算符允许您选择 BSON类型 17，即Timestamp数据类型。

如果查询没有返回相同的文档，则操作日志中的最后一个文档在ts字段中的数据类型错误。

例

如果第一个查询将其作为最后一个oplog条目返回：

复制

{ "ts" : {t: 1347982456000, i: 1},
  "h" : NumberLong("8191276672478122996"),
  "op" : "n",
  "ns" : "",
  "o" : { "msg" : "Reconfig set", "version" : 4 } }

而第二个查询返回此作为最后一个条目，其中ts 有Timestamp类型：

复制

{ "ts" : Timestamp(1347982454000, 1),
  "h" : NumberLong("6188469075153256465"),
  "op" : "n",
  "ns" : "",
  "o" : { "msg" : "Reconfig set", "version" : 3 } }

然后，ts最后一个oplog条目中的字段的值是错误的数据类型。

要为此值设置适当的类型并解决此问题，请使用类似于以下内容的更新操作：

复制

db.oplog.rs.update( { ts: { t:1347982456000, i:1 } },
                    { $set: { ts: new Timestamp(1347982456000, 1)}})

根据您的oplog条目，根据需要修改时间戳记值。该操作可能需要一段时间才能完成，因为更新必须扫描并将整个操作日志拉入内存。