Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs 菜单
Docs 主页
/

对没有主节点的副本集进行故障排除

副本集有时会进入主节点 (primary node in the replica set)不存在的状态,通常是在选举期间。但是,当主节点 (primary node in the replica set)长时间不存在时,副本集将无法接受写入。

本页包含对长时间没有主节点 (primary node in the replica set)的副本集进行故障排除的常见问题和解决方案。如果在完成以下部分后需要其他支持,联系 技术支持。

通过运行 或replSetGetStatus 方法,验证您的部署是否没有主节点rs.status() (primary node in the replica set)。以下示例显示了针对没有主节点 (primary node in the replica set)的副本集的 方法的输出:rs.status()

rs.status().members
[
{
_id: 0,
name: 'localhost:27018',
health: 1,
state: 2,
stateStr: 'SECONDARY',
...
configVersion: 2,
configTerm: 6,
self: true,
lastHeartbeatMessage: ''
},
{
_id: 1,
name: 'localhost:27019',
health: 1,
state: 2,
stateStr: 'SECONDARY',
...
configVersion: 2,
configTerm: 6
},
{
_id: 2,
name: 'localhost:27020',
health: 1,
state: 2,
stateStr: 'SECONDARY',
...
configVersion: 2,
configTerm: 6
}
]

注意

在某些情况下,您可能会看到rs.status() 输出将某些成员的stateStr 值显示为UNKNOWNDOWN

检查部署的日志消息中是否有组件 ()"c" 值为ELECTION 的条目。在这里,您可能会发现多次尝试启动选举均告失败,并在"msg" 字段中显示以下消息:

message
说明

“正在开始选举,因为我们在选举超时期内没有看到主节点”

当主节点 (primary node in the replica set)节点降级时由其他成员记录。

“我们收到的投票不足”

表示大多数节点未响应选举请求。成员可能已关闭或出现网络分区。

“看不到该设立的大多数,放弃主节点 (primary node in the replica set)”

成员可能已关闭或出现网络分区。

以下部分介绍可能导致副本集难以选择新主主节点 (primary node in the replica set)的常见问题以及解决方法。在联系支持部门之前,请检查以下问题是否会阻止您的部署选择主节点 (primary node in the replica set)。

如果您的部署出现网络分区,节点将无法相互通信,从而无法选举主节点 (primary node in the replica set)。

要验证您的部署是否受到网络分区的影响,请从不同节点运行replSetGetStatusrs.status() 方法。根据每个节点的输出,确定分区两侧的节点。

为了帮助在分区后恢复连接,请执行以下操作:

  • 检查防火墙配置是否有任何区块成员之间通信的规则。

  • 检查 DNS 主机名。

  • 确保将IP解决添加到IP访问列表中。

提示

一旦大多数节点可以相互访问, MongoDB就会自动选择一个主节点 (primary node in the replica set)并正常写入恢复。

确保您的主数据中心包含法定数量的投票节点和有资格成为主节点 (primary node in the replica set)的节点。如果副本集的主节点 (primary node in the replica set)宕机,并且没有从节点被选举主节点 (primary node in the replica set),请检查剩余节点是否都是优先级 0节点。

要检查每个节点的优先级值,运行replSetGetConfig 命令或rs.conf() 方法:

// Returns an array of documents corresponding with each member in your replica set
rs.conf().members
[
...
{
_id: 1,
host: localhost:27019,
arbiterOnly: false,
buildIndexes: true,
hidden: false,
priority: 0,
tags: {},
secondaryDelaySecs: Long('0'),
votes: 1
},
...
]

如果没有从节点因其优先级而有资格成为主节点members[n].priority (primary node in the replica set),更新一个或多个从节点的 值。有关详细说明,请参阅调整自管理副本集节点的优先级。

如果您的部署存在写入密集型工作负载、索引过多或占用大量磁盘空间的维护进程,则可能会使节点不堪重负并导致节点崩溃。

要回收磁盘空间,请考虑:

  • 删除未使用的集合或数据库。

  • 删除重复或未使用的索引。

  • 如果您有计划的 维护窗口,请考虑使用autoCompact 启用背景压实。

    警告

    autoCompact仅在流量较低期间(例如维护窗口)运行 。在高流量数据库上,背景压实可能会延迟或阻止备份等操作任务。要在启用背景压实之前学习;了解有关性能影响和其他注意事项的更多信息,请参阅 autoCompact 行为。

要监控磁盘使用情况:

  • 在Atlas上,您可以查看集群监控中提供的Disk Usage 图表。

  • 在自管理部署中,运行dbStats 命令或db.stats() 方法。

如果多个有投票权成员关闭且副本集失去多数成员,则 rs.status() 输出可能会显示所有成员均处于 SECONDARYRECOVERING 状态。以下情况可能导致失去多数:

示例,假设有一个三节点副本集,您可以同时关闭两个节点进行维护。在这种情况下,副本集将失去多数节点,并且在第三个成员备份之前无法选举新的主节点 (primary node in the replica set)。

为避免这种情况,请确保按顺序执行滚动维护,从从节点(secondary node from replica set)开始,到主节点 (primary node in the replica set)结束。这可确保主节点 (primary node in the replica set)始终可用。有关副本集维护的指导,请参阅对自管理副本集成员执行维护。

示例,考虑一种具有两个数据承载节点和一个隐藏的无投票节点的部署。如果一个承载数据的成员发生故障,则其余成员无法形成多数。

在使用 写关注(write"majority" concern)的主节点-从节点-仲裁节点 (PSA)拓扑结构中,如果从从节点(secondary node from replica set)因维护而停机,写入会停止。主节点 (primary node in the replica set)无法获得多数确认,因为两个承载数据的投票节点中只有一个可用。如果不对写入操作设立wtimeout,则写入会无限期区块。为了缓解这个问题,请执行以下操作:

  • 在维护窗口期间限制写入操作,以限制停止写入的数量。

  • 对使用 "majority"写关注(write concern)的写入操作设置 wtimeout 参数,以防止写入无限期阻塞。

有关缓解 PSA 拓扑中性能问题的更多详细信息,请参阅缓解自管理 PSA 副本集的性能问题。

在主节点-从节点-从节点-从节点-仲裁节点 (PSSSA)拓扑结构中,将多数投票节点放在单个数据中心或灾难恢复 (DR)站点会导致失去多数投票的风险。如果该地区完全宕机,则其余成员无法形成多数成员,也无法选举主节点 (primary node in the replica set)。将有投票权成员分布到各区域,以便在单区域故障后多数成员仍然可用。有关指导,请参阅数据中心感知。

恢复部署并选出新的主节点 (primary node in the replica set)后,rs.status() 输出将显示您的一个成员处于 PRIMARY 状态。

如果无法解决问题,联系技术支持并提供以下诊断信息:

  • 相关日志消息

  • rs.config() 输出

  • rs.status() 输出

后退

频繁选举

在此页面上