前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL 连接怎么保活?

MySQL 连接怎么保活?

作者头像
csch
发布2022-12-20 20:20:41
4.9K0
发布2022-12-20 20:20:41
举报
文章被收录于专栏:一树一溪

多年前开发过一个异步发送订单短信、邮件通知的守护程序,每次程序启动时会创建数据库连接,后续读写数据库操作就一直复用这个连接。

某一天,用户反馈下单后收不到通知了,我们登录服务器看到程序还在运行。

经过排查确认,发生问题的这天,距离上一次有用户下单超过了 8 小时,MySQL 服务端已经自动断开连接了。

解决这个问题的办法比较简单,程序只要定期给 MySQL 发送请求,表示自己还活着,MySQL 就不会触发断开连接的操作了,这就是数据库连接保活的应用场景。

今天我们来聊聊数据库连接保活的原理和方式。

本文内容基于 MySQL 8.0.29 源码。

目录

  • 1. 概述
  • 2. wait_timeout 超时逻辑
  • 3. ping
  • 4. select
  • 5. 两种保活方式对比
  • 6. 总结

正文

1. 概述

MySQL 系统变量 wait_timeout,默认值是 28800 秒(8 小时),用于控制客户端多长时间没有给 MySQL 发送请求,MySQL 就自动断开连接。

如果我们的业务系统不那么闲,能隔三差五的给 MySQL 发送一些请求,数据库连接会一直处于活跃状态,也就不需要专门保活了。

有一些业务系统,低峰期可能很长时间都不会有读写请求,一旦间隔时间超过 wait_timeout,数据库连接就断开了,连接保活自然不可避免。

接下来我们聊聊 2 种连接保活方式,以及它们之间有什么不一样,在这之前,我们先来看看 wait_timeout 是怎么控制超时逻辑的。

2. wait_timeout 超时逻辑

客户端和 MySQL 建立连接之后,MySQL 每次开始等待客户端发送数据之前,都会根据系统变量 wait_timeout 的值设置最长等待时间:

代码语言:javascript
复制
bool do_command(THD *thd) {
  ……
  net = thd->get_protocol_classic()->get_net();
  my_net_set_read_timeout(net, thd->variables.net_wait_timeout);
  ……
}

上面代码中的 net_wait_timeout 就是系统变量 wait_timeout 的化身。

设置最长等待时间之后,接下来就是安静的等待了,执行等待操作的方法是 vio_io_wait()

代码语言:javascript
复制
int vio_socket_io_wait(Vio *vio, enum enum_vio_io_event event) {
  int timeout, ret;
  ……
  timeout = vio->read_timeout;
  ……
  switch (vio_io_wait(vio, event, timeout)) {
    ……
    case 0:
      /* The wait timed out. */
      ret = -1;
      break;
    ……
  }

  return ret;
}

如果达到了最长等待时间,客户端一直没有发送数据,vio_io_wait() 会返 0 表示超时

然后,程序会沿着调用栈一路返回到 net_read_raw_loop() 方法中,设置返回给客户端的错误码 ER_CLIENT_INTERACTION_TIMEOUT(4031),对应的错误信息为:

代码语言:javascript
复制
The client was disconnected by the server because of inactivity.
See wait_timeout and interactive_timeout for configuring this behavior.

准备好返回给客户端的错误码和错误信息之后,就会进行一系列断开连接相关的操作,最后把错误码和错误信息发送给客户端。

如果我们用的是 MySQL 自带的交互式客户端 mysql,发生超时之后,等下次再执行 SQL 语句时,就会看到这样的错误了:

代码语言:javascript
复制
mysql> SET wait_timeout = 10;
10 秒之后......
mysql> SELECT * FROM t1 LIMIT 1;
ERROR 4031 (HY000): The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior.
No connection. Trying to reconnect...

对 MySQL 服务端主动断开连接过程大概介绍之后,接下来看看 2 种连接保活方式。

3. ping

站在客户端的视角看,使用 ping 命令是为了判断 MySQL 服务端是否还活着。

换一个角度,在 MySQL 服务端看来,一个客户端给它发送了 ping 命令,说明这个客户端连接还活着,它就不会把这个客户端的连接关闭。

所以,ping 命令不但可以用于数据库连接探活,还可以用于保活

MySQL 没有提供 ping 语句,如果想测试发送 ping 命令,可以使用 mysqladmin

代码语言:javascript
复制
# 发送 ping 命令
mysqladmin -h127.0.0.1 -P 3307 -uroot ping

# 收到的结果(表示 MySQL 服务端还活着)
mysqld is alive

在数据库连接池或者业务系统中,通过程序提供的 API 也能很方便地发送 ping 命令给 MySQL 服务端。

在业务低峰期,客户端定时给 MySQL 服务端发送 ping 命令,就能给连接保活了。

4. select

另一种连接保活方式是执行 SQL 语句,一般都是 select 语句,可以有各种花样:

代码语言:javascript
复制
SELECT 1;
SELECT version();
SELECT @@version;
……

执行 select 语句保活,和正常执行业务 SQL 没什么区别,这里不展开了。

5. 两种保活方式对比

既然 ping 和 select 都能实现数据库连接保活,那它们之间有什么不一样?

在MySQL 源码的实现中,体现了 2 点区别:

区别 1:ping 是命令,我们只能通过 MySQL 提供的 API,或 mysqladmin 这样的工具发送 ping 命令给 MySQL 服务端。

select 是 SQL 语句,通过 MySQL API 或 mysql 交互式客户端都能执行 select 语句。

区别 2:ping 的执行流程比 select 更短,效率更高,通过对比两者的调用栈,我们能更直观的看到这一点。

两种方式都会响应客户端请求,后面给出的调用栈中,把这部分省略了。

ping 命令的主要调用栈如下:

代码语言:javascript
复制
| > pfs_spawn_thread(void*)
| | > handle_connection(void*)
| | | > do_command(THD*)
| | | | > dispatch_command(THD*, COM_DATA const*, enum_server_command)

ping 命令的调用栈很简单,连词法解析、语法解析过程都不需要,进入 dispatch_command() 方法之后,判断是 ping 命令,就直接给客户端返回 OK 状态,整个流程就结束了:

代码语言:javascript
复制
bool dispatch_command(THD *thd, const COM_DATA *com_data,
                      enum enum_server_command command) {
  ......
  switch (command) {
    ......
    case COM_PING:
      thd->status_var.com_other++;
      my_ok(thd);  // Tell client we are alive
      break;
    ......
  }
  ......
}

接下来是 select 的调用栈,以最简单的 SELECT 1 为例,主要调用栈如下:

SELECT 1 的调用栈比较长,把主要调用栈都列出来是为了大家对 SELECT 1 的执行过程有更直观的了解。

代码语言:javascript
复制
| > pfs_spawn_thread(void*)
| | > handle_connection(void*)
| | | > do_command(THD*)
| | | | > dispatch_command(THD*, COM_DATA const*, enum_server_command)
| | | | | > dispatch_sql_command(THD*, Parser_state*)
| | | | | | > parse_sql(THD*, Parser_state*, Object_creation_ctx*)
| | | | | | > mysql_execute_command(THD*, bool)
| | | | | | | > Sql_cmd_dml::execute(THD*)
| | | | | | | | > Sql_cmd_dml::prepare(THD*)
| | | | | | | | | > open_tables_for_query(THD*, TABLE_LIST*, unsigned int)
| | | | | | | | | | > open_tables(...)
| | | | | | | | | | | > lock_table_names(...)
| | | | | | | | | | > open_secondary_engine_tables(THD*, unsigned int)
| | | | | | | | | > Sql_cmd_select::prepare_inner(THD*)
| | | | | | | | | | > Query_block::prepare(THD*, mem_root_deque<Item* > *)
| | | | | | | | | | | > Query_block::setup_tables(THD*, TABLE_LIST*, bool)
| | | | | | | | | | | > setup_fields(...)
| | | | | | | | | | | > Query_block::setup_conds(THD*)
| | | | | | | | | | | > Query_block::resolve_limits(THD*)
| | | | | | | | | | | > Query_block::apply_local_transforms(THD*, bool)
| | | | | | | | | | | | > Query_block::simplify_joins(...)
| | | | | | | | > lock_tables(THD*, TABLE_LIST*, unsigned int, unsigned int)
| | | | | | | | > Sql_cmd_dml::execute_inner(THD*)
| | | | | | | | | > Query_expression::optimize(THD*, TABLE*, bool, bool)
| | | | | | | | | | > Query_block::optimize(THD*, bool)
| | | | | | | | | | | > JOIN::optimize(bool)
| | | | | | | | | | | | > JOIN::make_tmp_tables_info()
| | | | | | | | | | | | > count_field_types(...)
| | | | | | | | | | | | > JOIN::create_access_paths()
| | | | | | | | | | | | | > JOIN::create_root_access_path_for_join()
| | | | | | | | | | | | | > JOIN::attach_access_paths_for_having_and_limit(AccessPath*)
| | | | | | | | | | | | | > JOIN::attach_access_path_for_delete(AccessPath*)
| | | | | | | | | > optimize_secondary_engine(THD*)
| | | | | | | | | > Query_expression::execute(THD*)
| | | | | | | | | | > Query_expression::ExecuteIteratorQuery(THD*)
| | | | | | | | | | | > Query_result_send::send_result_set_metadata(...)
| | | | | | | | | | > Query_expression::ExecuteIteratorQuery(THD*)
| | | | | | | | | | | > FakeSingleRowIterator::Read()
| | | | | | | | | | | > Query_result_send::send_eof(THD*)
| | | | | | | > trans_commit_stmt(THD*, bool)
| | | | | | | | > MYSQL_BIN_LOG::commit(THD*, bool)
| | | | | | | | | > ha_commit_low(THD*, bool, bool)
| | | | | > log_slow_statement(THD*, System_status_var*)

从上面的调用栈可以看到,SELECT 1 虽然不需要从表里查询数据,但是词法解析、语法解析、查询准备、查询优化、查询执行、事务提交、记录慢 SQL 等等这些流程一个都没落下,虽然很多方法进去之后,并不需要执行复杂的操作,但是各种 if ... else 判断是少不了要执行的。

SELECT 1 是 select 语句最简单的形式了,如果用其它 select 语句保活,调用栈只会更长。

通过上面 ping 命令 和 SELECT 1 的调用栈对比,相信大家对这两种保活方式的执行效率已经有了直观的了解。

6. 总结

本文写作的初衷就是为了对比 ping 和 select 两种数据库连接保活方式的执行效率。

经过前面的介绍,我们就可以得出结论了: ping 命令的执行效率比 select 语句高,对于追求极致性能的应用来说,使用 ping 命令给数据库连接保活是更好的方式


本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-10-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 一树一溪 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 概述
  • 2. wait_timeout 超时逻辑
  • 3. ping
  • 4. select
  • 5. 两种保活方式对比
  • 6. 总结
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档