副本集有时会进入主节点 (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 } ]
检查日志消息
检查部署的日志消息中是否有组件 ()"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)。
要验证您的部署是否受到网络分区的影响,请从不同节点运行replSetGetStatus 或rs.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() 输出可能会显示所有成员均处于 SECONDARY 或 RECOVERING 状态。以下情况可能导致失去多数:
滚动维护执行不正确
示例,假设有一个三节点副本集,您可以同时关闭两个节点进行维护。在这种情况下,副本集将失去多数节点,并且在第三个成员备份之前无法选举新的主节点 (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()输出