MySQL Connect-Timeout 引发的血案
MySQL Connect-Timeout 引发的血案
这件血案啊！还要从高可用说起。对于一套高可用系统来说，通常情况下应用层是无状态的，并且它的结点众多，所以就算有几台机器死机对它的影响也不大。
如果它的后台数据库(MySQL)死了，那基本上就没有然后了。为了解决一台数据库的单点问题，业界通常是做一个一主多从的架构，在 MySQL 主结点死掉后，把流量切到从结点上去；像这样的一套 MySQL 架构我们称之为一套 MySQL 高可用集群。
故事在这里还没有完，对于一套大型的分布式系统而言，它的后面可能是几十，几百套 MySQL 高可用集群为其做支撑。
事情发展到这个程度，业务变的有资本了，他们会想“故障发生时 MySQL 主从切换失败我们要怎么办？” 以前只有一套数据库，切换失败了大家就都完了。现在有多套了业务完全有“基础”在一套 MySQL 不能提供服务的情况下把流量切到其它 MySQL 集群上去。
业务解决思路
现在假设业务有两套集群 01、02 ，业务就是想在他检测到 01 有问题的时候把 01 上的流量全部切到 02 上去，这样他就不依赖于低层的 MySQL 主从切换了。
同理 02 有问题的时候，业务也主动把流量切到 01 上去；那现在技术上就变成了检查到有问题就切走，检测到可用之后业务又切回来。
由代码来完成应用程序的所有切换不用人参与。
检查方法
业务对于 MySQL 是否可用的检查方法是“先把数据读出来，然后再把数据更新回去”，如果这个可以正常完成说明数据库是可以读写的。由于我这里只是想讲一个参数，我们检查逻辑简化一下变成只要数据库可读(也可以规避掉一些保密上的问题)，就认为数据库的服务是正常的。业务的语言用的是 C++ 这里我为了方便用 Python 代替一下。
from mysql import connector
import logging
logging.basicConfig(level=logging.DEBUG)
#
check_sql = "select now();"
def is_mysql_available():
cnx = None
try:
cnx = connector.connect(host="127.0.0.1",port=3306,user="appchecker",password="xxxxxx",connect_timeout=1)
cursor = cnx.cursor()
# 执行检查 SQL
cursor.execute(check_sql)
_ = len(cursor.fetchall())
return True
except Exception as err:
logging.exception(err)
return False
if __name__ == "__main__":
if is_mysql_available():
print("mysql server is online")
else:
print("mysql server is offline")正常情况下检测逻辑没有任何问题，可以正常的完成它的功能。
python3 main.py
mysql server is online业务的检查失败了
那天业务的检查程序报 MySQL 连接不上，但是 MySQL 活的好好的。各自都有铁证，我这边 MySQL 进程一直在，并且有写入，他拿出了他的报错信息。
Lost connection to MySQL server at 'xx.xxx.xx.xxx:3306'定位问题
当时从 MySQL 的错误日志和 linux 的系统日志上都没有发现问题，唯一有记录的日志就是慢日志，问题发生的那个时间点只有 4 条 select count(1) from t 执行时间超过了 7 秒。t 类型的表 ibd 文件 32G，当时有 4 条连接同时在 count，磁盘 IO 都跑满了。
难不成只是因为他的检查程序，受到了其它 SQL 的影响，执行的慢了一点就报 MySQL 断开了它的连接，这个程序不行啊，受不了一点委屈！
问题只能说相对比较明确了，由于我对 MySQL 连接驱动比较熟悉，所以这次并没有直接去搞 mysql-server 。我就把驱动上与超时相关的代码看了一下，巧了还真被我发现了。
# 其一
self._connection_timeout = DEFAULT_CONFIGURATION["connect_timeout"]
# 其二
try:
self.sock = socket.socket(self._family, socktype, proto)
self.sock.settimeout(self._connection_timeout)
self.sock.connect(sockaddr)
except IOError as err:
... ...
except Exception as err:
raise errors.OperationalError(str(err))
可以看到 connet_timeout 会直接把客户端 socket 对象的超时时间给改了,这也就是一旦超时 tcp 连接就断了的原因。
复现问题
分析到这里要复现问题就比较简单了，我只要把 connect_time 设置为 1 ，然后构造出一条执行时间超时 1 秒的 SQL 就行了(这里可以直接用 sleep) 。
好现在我们模拟一下业务的配置和逻辑
from mysql import connector
import logging
logging.basicConfig(level=logging.DEBUG)
check_sql = "select sleep(2);"
def is_mysql_available():
cnx = None
try:
cnx = connector.connect(host="127.0.0.1",port=3306,user="appchecker",password="xxxxxx",connect_timeout=1)
cursor = cnx.cursor()
# 检查 SQL
cursor.execute(check_sql)
_ = len(cursor.fetchall())
return True
except Exception as err:
logging.exception(err)
return False
if __name__ == "__main__":
if is_mysql_available():
print("mysql server is online")
else:
print("mysql server is offline")运行效果
Traceback (most recent call last):
File "/private/tmp/pys/main.py", line 16, in is_mysql_available
cursor.execute(check_sql)
File "/usr/local/lib/python3.9/site-packages/mysql/connector/cursor.py", line 569, in execute
self._handle_result(self._connection.cmd_query(stmt))
File "/usr/local/lib/python3.9/site-packages/mysql/connector/connection.py", line 598, in cmd_query
result = self._handle_result(self._send_cmd(ServerCmd.QUERY, query))
File "/usr/local/lib/python3.9/site-packages/mysql/connector/connection.py", line 354, in _send_cmd
return self._socket.recv()
File "/usr/local/lib/python3.9/site-packages/mysql/connector/network.py", line 293, in recv_plain
raise errors.OperationalError(
mysql.connector.errors.OperationalError: 2055: Lost connection to MySQL server at '127.0.0.1:3306', system error: The read operation timed out
mysql server is offline好现在看到报错中的 `Lost connection to MySQL server at '127.0.0.1:3306'` 了，问题完美的复现了。
腾讯云开发者
