在mysql中通过binlog + sql定位是哪台服务器的常驻进程执行了SQL流程步骤

数据库  /  管理员 发布于 2年前   616

场景：一个 PHP 的常驻进程的任务，会定时执行一条更新 MySQL 数据的操作。

由于这里的逻辑处理有问题，他已经把执行更新的操作注释了，然后更新了代码，并重启了进程（注：常驻进程更新代码后需要重启进程才会生效）。

但是发现这条更新操作还是会定时执行，很明显还有没有重启的进程仍在调用之前的逻辑。

但是应该如何定位到是哪台机器的进程执行的呢？

思路分析：

业务场景的架构图：

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

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

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

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

SHOW VARIABLES LIKE 'log_bin';

结果如下：

Variable_name  | Value
log_bin      | ON

可以看到，现在 binlog 状态是开启的，

如果没有开启的话，可以使用以下命令开启：

SET GLOBAL general_log = ON;

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

SHOW MASTER STATUS;

结果如下：

File
mysql-bin.000030

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

SHOW VARIABLES LIKE 'log_bin_basename';

结果如下：

Variable_name       | Value
log_bin_basename     | /use/local/mysql/var/mysql-bin

因为我们的 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
localhost:33990

通过HOST字段我们可以定位到连接客户端的IP和端口号，到这里，我们已经看到胜利的曙光了。

接下来我们只要看一下这个端口被哪个进程占用就可以了。

登录到目标服务器（这里是 localhost 是指 MySQL 本地服务器），

使用以下命令查看占用端口号的程序：

lsof -i:端口号

如下图所示：

从结果可以看出是22617这个进程创建的MySQL连接并执行了这条更新，

可以通过以下命令查看进程的相关信息：

ps -p {pid} -f

如下图所示：

根据进程的启动时间可以分析出来，这个进程没有重启或关闭，导致一直执行之前的代码逻辑。

直接 kill 掉这个进程，发现数据不会被更新了，恢复正常。

总结

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

1.通过binlog可以定位到执行 SQL 的线程相关信息；

2.通过PROCESSLIST表可以定位到线程的基本信息，包括连接客户端的IP和端口号；

3.结合lsof、netstat和ps等进程相关的命令，可以定位到具体的进程信息，从而找到问题的根本。