本文记录了一次因存储故障引发的中间件连接超时问题的排查过程。故障表现为应用偶发连接建立不上，经过对日志、网络、数据库的深入分析，发现是HBA卡故障导致的数据库commit慢，进而影响到前端应用。最终通过主从切换解决紧急问题，并在中间件层面优化，防止类似问题再次发生。
解Bug之路，记一次存储故障的排查过程
高可用真是一丝细节都不得马虎。平时跑的好好的系统，在相应硬件出现故障时就会引发出潜在的Bug。偏偏这些故障在应用层的表现稀奇古怪，很难让人联想到是硬件出了问题，特别是偶发性出现的问题更难排查。今天，笔者就给大家带来一个存储偶发性故障的排查过程。
Bug现场
我们的积分应用由于量非常大，所以需要进行分库分表，所以接入了我们的中间件。一直稳定运行，但应用最近确经常偶发连接建立不上的报错。报错如下:
GetConnectionTimeOutException
而笔者中间件这边收到的却是:
NIOReactor - register err java.nio.channels.CloasedChannelException
这样的告警。整个Bug现场如下图所示:
偶发性错误
之前出过类似register err这样的零星报警，最后原因是安全扫描，并没有对业务造成任何影响。而这一次，类似的报错造成了业务的大量连接超时。由于封网，线上中间件和应用已经稳定在线
最低0.47元/天 解锁文章
扫一扫
1869
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
