一次Debug过程的思考

    前一段时间,部门接入了新业务,由于业务量小,架构非常简单,采用了最简单的LNMP架构,整个项目是交给一个刚毕业的RD负责的,这是背景。

    上线前半天,服务平稳运行。下午的时候,开始收到大量报警:No host could be connected in the cluster。第一反应:mysql服务器不会挂了吧。打开监控,一切正常,登录也一切正常,但报警一直没有间断,这奇怪了。

    实际上一点都不奇怪。“No host could be connected in the cluster”本身不是mysql的错误,所以并不是mysql服务器本身出了问题,问题的原因一定是出在封装的底层的类库,为了描述的更明白一些,我先总结一下这个mysql连接管理类库的功能。

    为了保证mysql服务的稳定性,我们的mysql连接类库实现了一个故障自动切换的功能:维护一个当前的mysql服务器的列表,每次连接时随机选择一台服务器连接(这里不考虑跨机房的问题,也不考虑选择的算法。选择机器的算法可以是随机的,也可以是轮询的,这不是关键),同时维护一个失败的服务器列表。如果某一次mysql执行失败,那么便把这台服务器从可用的服务器中摘除,同时放置到失败的服务器列表中, 在一定时间内(interval,比如2s)这台mysql便不在被访问。 需要注意的是,这台mysql并不是一直在失败的服务器列表中的,经过一段时间后,便会重新释放,重新进入可用的服务器列表中。这么做的主要目的,是在某一台mysql服务器发生故障时,由于这台mysql被访问到的概率变小,不至于出现线上服务的大面积瘫痪,也给线上故障转移提供更多的时间buffer。

    问题就出在这里!这个自动切换的功能只适用于mysql cluster,也就是存在多个mysql服务器的情况,如果服务器只有一台,那么问题就很严重了:如果某一次mysql查询执行失败了,那么这台mysql会被打入冷宫,在接下来的时间间隔内,便没有任何可用的mysql服务器了!这样一来,流量一大,所有的interval间隔内的请求便都失败了!这也是为什么线上会出现大量的“No host could be connected in the cluster”的报警。

    这个问题很典型,很多人不清楚类库的作用,便信手拈来直接使用,所以出现问题的时候常常也是一头雾水,不知从何下手。尤其在大公司中,类库、工具、成熟的解决方案都比较齐全,在使用方便的同时,也隐藏了内部的实现逻辑,往往会造成“使用很熟练,原理一窍不通”的问题。

知识改变命运,码农拯救人生
posted @ 2016-04-30 16:42  ohmygirl  阅读(495)  评论(0编辑  收藏  举报

知识改变命运,码农拯救人生

ohmygirl@2014