一个问题场景:业务请求查询数据库,当请求没有成功返回时(这里是数据库机器异常,表现是不返回请求结果,处于假死状态),业务挂起进入等待(WAIT),逻辑中断,表现为卡顿、持续加载中;高并发场景下,短时间内堆积的请求会大量占用发起数据库请求的机器的内存(风险一),大量业务卡顿异常;当数据库异常解决成功返回后,大量堆积的请求会瞬间打到数据库机器上,引起数据库资源占用波动(风险二);
原因:副本集primary机器内存异常,导致primary机器处于假死状态,丧失消费查询请求的能力,此时副本集心跳检查无法获取异常状态,异常状态持续。后续堆积请求达到primary机器资源承受上线,机器被击穿,此时副本集感知到primary机器异常,选举策略推选secondary机器为primary,淘汰假死的机器,新primary机器开始释放堆积请求。
这里的问题是:副本集无法感知到上述假死状态下的机器及时更新重选,导致业务长期处于瘫痪状态。
标签:副本,机器,请求,mongoDB,数据库,假死,primary,失效 From: https://www.cnblogs.com/linxx-/p/18091081