MongoDB副本集Secondary节点显示不可达 连接被拒绝故障咨询

从你提供的rs.status()输出可以直接锁定根因方向：两个Secondary节点（127.0.0.1:27027、127.0.0.1:27037）的心跳报错为目标机器主动拒绝连接，节点uptime为0。
TCP层面的连接被主动拒绝，本质就是对应端口没有服务监听，说明这两个端口对应的mongod进程根本没有运行，不是副本集配置、跨节点网络策略的问题——如果是网络拦截、配置不匹配，会出现连接超时、握手失败的报错，不会触发主动拒绝。加上故障触发场景是机器重启后，这类双Secondary同时不可达的情况，绝大多数是Secondary节点没有配置开机自启，或者自启流程因为启动失败中断。

1. 核验进程监听状态 #

在服务器上直接执行两条命令确认端口状态：

• ps aux | grep mongod：列出所有正在运行的mongod进程，确认是否有对应27027、27037端口的进程条目
• ss -tlnp | grep -E '27027|27037'：查看端口监听情况，如果完全没有对应端口的监听记录，就可以直接确认是进程未启动

注：你的副本集所有节点都部署在127.0.0.1本地，不存在跨机器防火墙、安全组拦截的可能，不用在网络权限类的排查上浪费时间。

2. 定位进程启动失败的原因 #

如果确认两个端口的mongod进程没有运行，直接查看对应节点的日志文件（日志路径来自mongod配置文件里systemLog.path的配置项），重点看启动阶段的报错，常见的重启后启动失败原因包括：

• 数据目录权限异常：硬重启后挂载的数据盘未正常连接，或者数据目录的属主从mongodb运行用户变成了root，导致mongod无法写入WiredTiger存储引擎的锁文件
• 端口被占用：重启后其他应用抢占了27027/27037端口，导致mongod启动时绑定端口失败直接退出
• 元数据损坏：非正常关机导致oplog集合、WiredTiger元文件损坏，mongod启动时自检不通过直接退出
• 无自启配置：之前是手动启动的Secondary节点，没有配置系统级开机启动项，机器重启后进程自然不会自动拉起

3. 节点恢复与长效配置 #

• 按照日志提示解决对应的启动故障后，手动用对应配置文件拉起两个Secondary的mongod进程，例如：
  mongod --config /etc/mongod/27027.conf
mongod --config /etc/mongod/27037.conf
• 回到Primary节点的mongo shell中再次执行rs.status()，等待2-3个心跳周期（约5秒），确认两个节点的health值恢复为1，状态变为SECONDARY
• 验证节点运行正常后，给两个Secondary配置systemd系统服务，执行systemctl enable命令开启开机自启，避免下次机器重启再次出现同类问题

• 不要上来就执行rs.remove()删除副本集里的Secondary节点，当前的连接失败是进程层面的问题，不是副本集配置层面的问题，删节点再加只会增加不必要的操作风险
• 不要看到启动失败就直接删除整个数据目录，先通过日志定位根因，避免造成数据丢失

内容的提问来源于stack exchange，提问作者rakesh pakkam