MySQL 实用小技巧——谁动了我的 MySQL ？

背景介绍

前两天，一位开发的小伙伴找到我，向我反馈了这样一个问题：

一个 PHP 的常驻进程的任务，会定时执行一条更新 MySQL 数据的操作。由于这里的逻辑处理有问题，他已经把执行更新的操作注释了，然后更新了代码，并重启了进程（注：常驻进程更新代码后需要重启进程才会生效）。但是发现这条更新操作还是会定时执行，很明显还有没有重启的进程仍在调用之前的逻辑。但是应该如何定位到是哪台机器的进程执行的呢？

分析定位

我们先来梳理下这个业务场景的架构关系，如下图所示：

如上图所示，现在需要定位到是哪一个常驻进程执行了这条更新的 SQL。

因为常驻进程可能存在于不同的机器上，所以我们首先要定位到这条 SQL 是哪个在哪个机器上调用的，定位到机器以后再来定位是哪个进程执行的。

我们都知道，MySQL的 binlog 记录了 MySQL 的执行过的语句，常用于数据恢复和问题定位，这里我们看能不能通过 binlog 找到一些和执行 SQL 相关的客户端信息。

首先我们需要确认是否开启了 binlog，在 MySQL 控制台执行以下语句：

SHOW VARIABLES LIKE 'log_bin';

结果如下：

可以看到，现在 binlog 状态是开启的，如果没有开启的话，可以使用以下命令开启：

SET GLOBAL log_bin = ON;

然后我们需要确定 binlog 文件的位置，执行以下语句：

SHOW MASTER STATUS;

结果如下：

这条语句可以查到 binlog 的文件名称，还需要通过以下语句查询到 binlog 的完整路径：

SHOW VARIABLES LIKE 'log_bin_basename';

结果如下：

因为我们的 MySQL 是安装在服务器上的，所以可以直接在服务器上进行分析 binlog。直接使用文本查看工具打开 binlog 的话是一堆乱码，这是因为 binlog 本身是以二进制文件存储的，所以需要通过其他工具处理以后查看，这里我们使用 MySQL 自带的 mysqlbinlog 进行处理。

使用 mysqlbinlog 命令将反编译以后的内容输出到一个文本文件中：

/usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/var/mysql-bin.000030  > ~/binlog.txt

说明：mysqlbinlog 客户端一般安装在 MySQL 的命令目录下。

查看文件，按照关键字搜索到 SQL 执行到相关信息：

cat ~/binlog.txt | grep -B5 '{keyword}'  | tail -5

输出结果如下：

这里可以看到执行 SQL 的线程ID（thread_id）是 116，根据这个线索，我们可以查询到这个线程执行到相关信息，使用如下语句：

SELECT
    `HOST`
FROM
    `information_schema`.`PROCESSLIST`
WHERE
    `id` = {thread_id}

查询到的结果如下（这里只关注客户端连接信息即可）：

通过 HOST 字段我们可以定位到连接客户端的 IP 和 端口号，到这里，我们已经看到胜利的曙光了。接下来我们只要看一下这个端口被哪个进程占用就可以了。

登录到目标服务器（这里是 localhost 是指 MySQL 本地服务器），使用以下命令查看占用端口号的程序：

lsof -i:端口号

输出结果如下：

从结果可以看出是 22617 这个进程创建的 MySQL 连接并执行了这条更新，可以通过以下命令查看进程的相关信息：

ps -p {pid} -f

输出结果如下：

根据进程的启动时间可以分析出来，这个进程没有重启或关闭，导致一直执行之前的代码逻辑。直接 kill 掉这个进程，发现数据不会被更新了，恢复正常。

总结

通过这个例子，我们可以总结到以下经验：

• 通过 binlog 可以定位到执行 SQL 的线程相关信息；
• 通过 PROCESSLIST 表可以定位到线程的基本信息，包括连接客户端的 IP 和 端口号；
• 结合 lsof、netstat 和 ps 等进程相关的命令，可以定位到具体的进程信息，从而找到问题的根本。

本作品采用《CC 协议》，转载必须注明作者和本文链接