记一次坑爹的问题排查过程,mongoDB 集群节点切换导致用户查看数据超时

问题还原: 教育部平台admin查看通知公告列表无异常,切换为下级账号查看通知公告列表无异常,点击查看通知详情,无法加载,报 504 gateway time-out .超时

排查过程:登录教育部平台系统,首先登陆gateway查看接口无异常,预计问题出在php接口调后端接口超时,查看后端日志.发现

初次排查 : 第一次遇到此问题,网上搜索问题所在是http 或者tcp连接异常断开的缘故. (注意!此处正式坑所在,这个Exception相当宽泛,仅由此排查问题在php调后端接口过于草率.由于gateway调后端接口无问题,所以我认为问题出在php处,调整了php封装好的curl方法的超时时间,以及nginx的send_time_out 之后,重启前端服务,问题没有解决.)

教训 : 不要想当然! ,gateway调用接口时使用的还是admin账号,admin账号调用无问题,默认后端接口无问题,这是不可取的.

第二次排查 : 查看mongo服务是否正常,登录mongo服务的物理机,查看内存和cpu占用情况,没什么异常,出于尝试,把mongo服务重启了一遍.再次测试还是没有解决.

第三次排查 : 仔细查看代码,发现admin和下级用户虽然调用同一个接口,但是下级用户在查看通知时会有一个update mongo通知人已读/未读 表的操作. 顺藤摸瓜,登录mongo服务,找了一条无用数据使用了update语句,果然报错. 信息是: not master and slaveOK=false

这正是问题所在! 由于我们的mongo是搭建了集群的,服务连接的27机器上的mongo原本是主节点,但可能由于网络等原因被集群认为挂掉之后,28的机器升级成为了master,而27服务在恢复之后成为了slave. 但是微服务的配置并没有相应更改. 导致下级用户在查看通知详情时,由于有update 通知人已读/未读 表的操作,所以报错了.