基于主-从-仲裁者架构的MongoDB故障转移测试问题排查

你的测试操作存在的问题 #

1. 故障转移等待时间不足：MongoDB副本集的故障转移（选举新主）默认需要10-30秒的时间，你设置的10秒休眠大概率不足以完成选举流程。此时客户端尝试查询时，副本集还处于无主状态，自然会触发超时。
2. 未配置合适的读偏好：默认情况下MongoDB客户端会优先读取主节点，当主节点挂掉且新主未选举完成时，客户端会持续尝试连接旧主节点，不会自动切换到从节点读取。即使选举完成，客户端也需要时间完成节点发现，你没有配置对应的读偏好（如secondaryPreferred）来支持故障时降级读从节点。
3. 忽略了主从仲裁架构对readConcern:majority的天然限制：主从仲裁架构只有1个真正存储数据的从节点，而readConcern:majority要求数据必须被复制到多数投票节点（3节点副本集的多数是2个节点）。但仲裁节点不存储数据，当主节点故障后，新主（从节点）无法获得其他数据节点的复制确认，readConcern:majority的查询会一直等待满足条件，最终超时。
4. 未验证副本集同步状态：测试前你没有确认从节点是否完成了全量同步、oplog是否正常，若从节点同步滞后，会进一步拖慢选举流程，甚至导致选举失败。

正确复现问题的步骤 #

1. 确保副本集配置正常：
   • 搭建主、从、仲裁3节点副本集，设置从节点priority=1、仲裁节点priority=0；
   • 通过rs.status()确认从节点状态为SECONDARY，且optimeDate与主节点一致（同步完成）。
2. 配置客户端连接参数：
   • 在C#连接字符串中指定读偏好：readPreference=secondaryPreferred，确保主节点故障时自动切换到从节点读取；
   • 配置合理的超时时间（如connectTimeoutMS=5000、socketTimeoutMS=10000）和重试策略。
3. 模拟故障并等待选举完成：
   • 运行C#程序，先执行几次正常查询确认连接正常；
   • 终止主节点进程后，等待30秒以上，通过rs.status()确认新主节点已选举成功（从节点变为PRIMARY）；
   • 再分别执行带/不带readConcern:majority的查询：
     • 不带readConcern:majority的查询应该能正常返回数据；
     • 带readConcern:majority的查询会超时或报错（因为无法满足多数节点确认的条件）。

修复方案 #

1. 调整副本集架构（推荐）：
   将主从仲裁架构改为至少3个数据节点（如主、从、从），这样即使主节点故障，剩下的两个从节点可以选举新主，且readConcern:majority的要求可以通过两个数据节点的复制确认满足。
2. 禁用readConcern:majority（临时方案）：
   如果无法调整架构，将读关注改为local或available，这样查询不会等待多数节点确认，主节点故障时可以直接读取从节点的数据，避免超时。
3. 优化客户端配置：
   • 强制设置读偏好为secondaryPreferred，确保故障时自动降级读从节点；
   • 配置客户端的重试机制，开启RetryWrites和RetryReads，让驱动在故障转移期间自动重试请求。
4. 调整副本集选举参数：
   适当缩短electionTimeoutMillis（默认10秒），加快选举速度，但不要设置过小（如低于5秒），避免因网络波动触发误选举。

内容的提问来源于stack exchange，提问作者Siddharth Mehrotra