MongoDB 4.x副本集与Oplog Tailing配置故障排查求助

首先，针对你的疑问：MongoDB版本差异确实是可能的诱因——MongoDB 4.0对副本集的配置规范比3.4更严格，再加上你当前的一些配置细节问题，共同导致了oplog tailing无法正常工作。下面是一步步的排查和修复方案：

1. 修正MONGO_OPLOG_URL的格式错误 #

你当前设置的mongodb://localhost:27017/local没有指定副本集标识，Meteor无法识别这是一个副本集环境，自然不会启用oplog tailing。正确的格式需要加上replicaSet参数，并且建议使用你配置的主机名myhostname（和副本集成员配置保持一致）：

修改Passenger配置文件/etc/nginx/sites-enabled/myappname.conf中的对应行：

passenger_env_var MONGO_OPLOG_URL mongodb://myhostname:27017/local?replicaSet=rs0;

修改后重启Nginx生效：

sudo systemctl restart nginx

2. 检查并修复副本集成员配置 #

MongoDB 4.0对副本集成员的主机名匹配要求更严格，默认执行rs.initiate()可能会用localhost作为成员主机名，但你修改了/etc/hosts映射到myhostname，这会导致节点间通信异常（也就是日志中"Unable to reach primary for set rs0"的原因）。

验证当前副本集配置 #

在Mongo Shell中执行：

rs.conf()

查看members数组中的host字段，如果显示的是localhost:27017而不是myhostname:27017，需要重新初始化副本集：

重新初始化副本集 #

先停止MongoDB服务：

sudo systemctl stop mongod

删除local数据库的相关文件（备份后操作，路径默认是/var/lib/mongodb/local.*）：

sudo rm /var/lib/mongodb/local.*

重启MongoDB：

sudo systemctl start mongod

进入Mongo Shell，执行自定义初始化命令（明确指定成员主机名）：

rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "myhostname:27017" }
  ]
})

等待几秒后执行rs.status()，确认stateStr字段显示为PRIMARY，说明副本集正常运行。

3. 确保MongoDB绑定地址允许主机名访问 #

检查/etc/mongod.conf中的net配置段，确保MongoDB监听的地址包含myhostname，或者允许所有本地地址：

方案一（指定明确地址）：

net:
  port: 27017
  bindIp: 127.0.0.1,myhostname

方案二（允许所有本地地址，更简单）：

net:
  port: 27017
  bindIpAll: true

修改后重启MongoDB：

sudo systemctl restart mongod

4. 验证oplog tailing是否生效 #

完成上述配置后，查看Meteor应用的日志（或Nginx的错误日志/var/log/nginx/error.log），确认没有oplog连接失败的报错。同时观察MongoDB日志/var/log/mongodb/mongod.log，如果之前的"Unable to reach primary"警告消失，且高频查询日志减少，说明oplog tailing已经正常启用。

额外提示 #

• 你的oplogSizeMB: 100设置偏小，如果应用数据更新频繁，可能会导致oplog被快速覆盖，建议根据业务量调整到512MB或更高。
• 虽然当前MongoDB无权限控制，但生产环境建议添加用户权限，限制oplog的访问范围（Meteor只需要读取oplog的权限）。

内容的提问来源于stack exchange，提问作者Little Brain