主页 / dba / 问题 / 186545
Accepted
tombom
Asked: 2017-09-22 03:59:40 +0800 CST

中断查询发送错误的线程 ID

  • 772

在 MySQL 命令行客户端 (Linux) 中，当我通过按CTRL+终止查询时，c这通常工作正常。

mysql (slave) > select sleep(5);
^CCtrl-C -- sending "KILL QUERY 117920686" to server ...
Ctrl-C -- query aborted.
+----------+
| sleep(5) |
+----------+
+----------+
1 row in set (0.78 sec)

然而，当我在我的实时主服务器（在所有服务器中，它必须是这一个......）上做同样的事情时，它以某种方式发送了错误的线程 ID。

mysql (master) > select sleep(5);
^CCtrl-C -- sending "KILL QUERY 770543254" to server ...
Ctrl-C -- query aborted.
+----------+
| sleep(5) |
+----------+
+----------+
1 row in set (5.00 sec) /* <- it obviously hasn't aborted at all */

ID太低了 其他线程的 ID 类似于 26534760326。所有服务器的版本相同：

# yum list installed mysql*
Loaded plugins: dellsysid, rhnplugin, security, ulninfo
This system is receiving updates from RHN Classic or Red Hat Satellite.
Installed Packages
MySQL-python.x86_64                                             1.2.3-0.3.c1.1.el6                              @public_ol6_latest
mysql-community-client.x86_64                                   5.6.27-2.el6                                    @mysql56-community
mysql-community-common.x86_64                                   5.6.27-2.el6                                    @mysql56-community
mysql-community-libs.x86_64                                     5.6.27-2.el6                                    @mysql56-community
mysql-community-libs-compat.x86_64                              5.6.27-2.el6                                    @mysql56-community
mysql-community-release.noarch                                  el6-5                                           @/mysql-community-release-el6-5.noarch
mysql-community-server.x86_64                                   5.6.27-2.el6                                    @mysql56-community

附加信息：

然而，该connection_id()函数返回正确的值。

root@ods01:(none) > select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|     26542310314 |
+-----------------+
1 row in set (0.00 sec)

root@ods01:(none) > select sleep(5);
^CCtrl-C -- sending "KILL QUERY 772506538" to server ...
Ctrl-C -- query aborted.
+----------+
| sleep(5) |
+----------+
+----------+
1 row in set (5.00 sec)

有谁知道如何解决这一问题？

mysql client

1 个回答

  1. Best Answer

    写错误报告！ http://bugs.mysql.com。

      26542310314 MOD 2^32 = 772506538

    也就是说，64 位的 connection_id 被截断为 32 位以发送 KILL，从而将其发送到错误的 ID。

    超过 40 亿连接的用户并不多。您的服务器启动了多长时间？我希望代码不会为每个查询重新连接。

    更改日志

    ----- 2014-09-25 5.7.5 里程碑 15 -- 错误修复 -- ------

    连接 ID 是 32 位无符号整数，从 1 开始。当服务器分配连接 ID 并达到 32 位范围的顶部时，它会将值重新从 1 开始。如果旧线程运行时间特别长，服务器可能会为新线程分配一个连接 ID，而该 ID 仍在由现有线程使用。对于这种情况，对 ID 的引用变得不明确。例如，无法可靠地确定KILL connection_id要杀死哪个线程，这可能会导致未定义的行为。此行为已得到纠正，因此使用中的 ID 不会被重复使用。连接 ID 是 32 位无符号整数，从 1 开始。当服务器分配连接 ID 并达到 32 位范围的顶部时，它会将值重新从 1 开始。如果旧线程运行时间特别长，服务器可能会为新线程分配一个连接 ID，而该 ID 仍在由现有线程使用。对于这种情况，对 ID 的引用变得不明确。例如，无法为KILL connection_id可靠地确定要杀死哪个线程，这可能会导致未定义的行为。此行为已得到纠正，因此使用中的 ID 不会被重复使用。

    ----- 2012-12-11 5.6.9 候选发布版 -- 修复了错误 -- 不兼容的更改 -----

    在某些系统（例如繁忙或长时间运行的 64 位系统）上可能会出现大于 32 位的连接 ID（线程 ID）值，从而导致这些问题：

    写入一般查询日志和慢查询日志的连接 ID 不正确。这对于记录到文件和表都是如此。

    CONNECTION_ID() 函数可能会返回一个数据类型对于大于 32 位的值来说太小的值。

    mysql_thread_id () 和 mysql_kill() C API 函数不处理大于 32 位的 ID 值。这可能导致杀死错误的线程；例如，如果您调用了 mysql_kill(mysql_thread_id())。

    当服务器支持它们时（当使用 64 位数据类型构建时），现在允许连接 ID 为 64 位值，这具有以下效果：

    连接 ID 已正确记录到一般查询日志和慢速查询日志中。

    注意此更改涉及对日志表的修改，因此升级到此版本后，您必须运行 mysql_upgrade 并重新启动服务器。

    CONNECTION_ID() 返回适用于大于 32 位的值的数据类型。

    mysql_thread_id() 不变；客户端/服务器协议的 ID 值只有 4 个字节。对于大于 32 位的连接 ID，此函数返回不正确（截断的）值，应避免使用。

    mysql_kill() 仍然无法处理大于 32 位的值，但为了防止杀死错误的线程现在在这些情况下返回错误：

    如果给出的 ID 大于 32 位， mysql_kill() 将返回 CR_INVALID_CONN_HANDLE 错误。

    服务器的内部线程 ID 计数器达到大于 32 位的值后，它 会 为任何 mysql_kill() 调用 返回ER_DATA_OUT_OF_RANGE错误，并且mysql_kill() 失败。

    为避免 mysql_thread_id() 和 mysql_kill()出现问题，请勿使用它们。要获取连接 ID，请执行 SELECT CONNECTION_ID() 查询并检索结果。要终止线程，请执行 KILL 语句。

    （错误#19806、错误#11745768、错误#65715、错误#14236124、错误#44728、错误#11753308）

    （小错误编号可以在 bugs.mysql.com 找到；大错误编号无法访问 - Oracle 内部。）

    所以，建议您升级到 5.6.9+ 或 5.7.5+。由于你在 5.6.27，所以有一个困惑。也许那个冗长的变更日志中的一些细节说了一些有用的东西。

    • 2

相关问题