点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
业务侧反馈A库业务无法正常访问，该业务涉及的数据库是万里greatdb数据库，DBA侧立即登入数据库进行分析处理，发现万里数据库A节点已经hang住，无法查询相关表数据。为了尽快恢复业务，通知万里厂家对数据库进行切换重启，主节点切换至B节点后，数据库恢复正常，业务恢复正常。
查看A节点主机nmon日志，发现主机内存资源在凌晨开始出现波动，剩余内存开始呈下降趋势，并且多次出现内存耗尽又恢复的情况。
1）发现日志故障前有大量的[Server] Aborted connection 2235021 to db: 'unconnected' user: ‘C用户’ host: ‘1XX.XXX.XXX.XXX’ (Got an error reading communication packets)报错，该用户为万里开源数据库管理账号，并且在切换到B节点上后，该错误消失，DBA侧分析为万里开源数据库密码修改后未生效导致，重启后密码生效后恢复，建议万里开源原厂核查原因。2）数据库在凌晨出现[Server] Got error 3044 when reading table './performance_schema/data_locks'错误后就hang住了，这个是获取分配内存失败的报错。这个时间点主机内存还有40g剩余，需要原厂分析获取内存失败的原因。集群正常的时候，从库事务日志分配event花费 group_replication_applier': seconds elapse在 120秒以内，但在开始大批量事务执行后，分配event耗时开始开始上涨，严重时刻达到几百，在某时间段甚至到900多秒。这时出现二次数据库节点从集群中断开的情况，切换完成后，从库事物日志分配event耗时稳定在120秒左右。至此，可以初步判断此次故障原因为大批量业务造成压力过大，事务延迟，导致会话不断积压引起数据库hang住。
