好的，我们开始今天的讲座，主题是关于使用 pstack 和 gdb 进行 MySQL 进程的堆栈跟踪与故障诊断。
引言：MySQL 进程故障诊断的重要性
MySQL 作为最流行的关系型数据库之一，其稳定性对业务至关重要。当 MySQL 进程出现问题，例如崩溃、挂起、性能急剧下降等，我们需要快速定位问题根源。堆栈跟踪 (Stack Trace) 是一种强大的诊断工具，它能够揭示程序在特定时刻的执行路径，从而帮助我们理解程序行为，找到导致问题的代码。pstack 和 gdb 是 Linux 系统下常用的堆栈跟踪工具，它们各有特点，适用于不同场景。
第一部分：pstack 的基本使用
pstack 是一个简单的命令行工具，用于打印进程的堆栈信息。它不需要任何配置，可以直接使用。
-
安装
pstack:在 Debian/Ubuntu 系统上：
sudo apt-get install pstack在 CentOS/RHEL 系统上：
sudo yum install pstack -
基本用法:
pstack <pid>其中
<pid>是 MySQL 进程的进程 ID。 可以通过ps命令或者pgrep命令找到 MySQL 进程的 PID。例如：ps -ef | grep mysqld # 或者 pgrep mysqld -
示例:
假设 MySQL 进程的 PID 是 1234，执行
pstack 1234，会输出类似下面的信息：Thread 1 (Thread 0x7f1c9d9e7700 (LWP 1234)): #0 0x00007f1c9c9a6e80 in poll () from /lib64/libc.so.6 #1 0x0000000000d49093 in mysqld_main (argc=3, argv=0x7ffd4b4334d8) at /path/to/mysql/sql/mysqld.cc:649 #2 0x0000000000d47199 in main (argc=3, argv=0x7ffd4b4334d8) at /path/to/mysql/sql/main.cc:25每一行
#开头的代表一个栈帧 (Stack Frame)。 栈帧包含了函数地址和函数参数 (如果可用)。 从上到下，表示函数调用的顺序，最上面的#0代表当前正在执行的函数。 -
pstack的局限性:pstack只能提供简单的堆栈信息，无法进行交互式调试，也无法查看变量的值。 对于复杂的故障，pstack可能不足以定位问题。 此外，如果 MySQL 进程被 strip 过 (去除了调试信息)，pstack输出的信息会比较有限，只能看到函数地址，无法看到函数名和文件名。
第二部分：gdb 的高级使用
gdb (GNU Debugger) 是一个强大的调试器，可以用来调试 C、C++ 等程序。 gdb 提供了丰富的命令，可以查看变量的值、设置断点、单步执行等。
-
安装
gdb:在 Debian/Ubuntu 系统上：
sudo apt-get install gdb在 CentOS/RHEL 系统上：
sudo yum install gdb -
基本用法:
gdb /path/to/mysqld <pid>其中
/path/to/mysqld是 MySQL 服务器的可执行文件路径，可以通过which mysqld命令找到。<pid>是 MySQL 进程的进程 ID。 -
常用
gdb命令:bt(backtrace): 打印堆栈信息。frame <number>: 切换到指定的栈帧。 例如frame 1切换到第二个栈帧。info locals: 打印当前栈帧的局部变量。print <variable>: 打印变量的值。 例如print argc打印argc变量的值。next: 单步执行下一行代码。continue: 继续执行程序。quit: 退出gdb。break <file>:<line>: 在指定文件和行号设置断点。 例如break mysqld.cc:649在mysqld.cc文件的第 649 行设置断点。break <function>: 在指定函数入口设置断点。 例如break mysqld_main在mysqld_main函数入口设置断点。info registers: 打印寄存器的值。x/<nfu> <addr>: 检查内存。n是要显示的内存单元的数量，f是显示格式，u是内存单元的大小。 例如x/10xw 0x7ffd4b4334d8从地址0x7ffd4b4334d8开始显示 10 个 16 进制的 word (4 bytes)。
-
示例:
假设 MySQL 进程的 PID 是 1234，执行以下命令：
gdb /usr/sbin/mysqld 1234进入
gdb界面后，输入bt命令，会输出堆栈信息，与pstack的输出类似，但gdb的输出更详细，包含了更多的信息。(gdb) bt #0 0x00007f1c9c9a6e80 in poll () from /lib64/libc.so.6 #1 0x0000000000d49093 in mysqld_main (argc=3, argv=0x7ffd4b4334d8) at /path/to/mysql/sql/mysqld.cc:649 #2 0x0000000000d47199 in main (argc=3, argv=0x7ffd4b4334d8) at /path/to/mysql/sql/main.cc:25然后，可以使用
frame 1命令切换到mysqld_main函数的栈帧，并使用info locals命令查看局部变量的值。(gdb) frame 1 #1 0x0000000000d49093 in mysqld_main (argc=3, argv=0x7ffd4b4334d8) at /path/to/mysql/sql/mysqld.cc:649 (gdb) info locals thd = 0x55f198d65700 ret = 0 ...如果怀疑某个变量导致了问题，可以使用
print <variable>命令查看变量的值。(gdb) print thd $1 = (THD *) 0x55f198d65700 -
gdb结合 Core Dump 文件进行调试:当 MySQL 进程崩溃时，可能会生成 Core Dump 文件。 Core Dump 文件包含了进程在崩溃时的内存映像，可以使用
gdb加载 Core Dump 文件进行离线调试。首先，需要配置系统，允许生成 Core Dump 文件。 修改
/etc/security/limits.conf文件，添加以下两行：* soft core unlimited * hard core unlimited然后，执行
ulimit -c unlimited命令使配置生效。接下来，当 MySQL 进程崩溃时，会在当前目录下生成一个
core文件 (文件名可能不同，取决于系统配置)。可以使用以下命令加载 Core Dump 文件进行调试：
gdb /usr/sbin/mysqld core加载 Core Dump 文件后，可以使用
bt命令查看崩溃时的堆栈信息，并使用frame、info locals、print等命令查看变量的值，分析崩溃原因。 -
使用
gdb附加到运行中的 MySQL 进程:除了使用
gdb加载 Core Dump 文件进行调试，还可以使用gdb附加到运行中的 MySQL 进程进行调试。 这种方式可以实时查看进程的状态，但需要小心操作，避免影响 MySQL 进程的正常运行。使用以下命令附加到运行中的 MySQL 进程：
gdb /usr/sbin/mysqld <pid>附加到进程后，可以使用
bt命令查看当前的堆栈信息，并使用break命令设置断点，逐步调试程序。注意: 附加到运行中的进程可能会导致进程暂停，影响服务可用性。 建议在测试环境或者非高峰时段进行调试。
第三部分：实际案例分析
为了更好地理解如何使用 pstack 和 gdb 进行 MySQL 进程的故障诊断，我们来看几个实际的案例。
-
案例一：死锁导致 MySQL 进程挂起
假设 MySQL 进程因为死锁而挂起，导致数据库无法响应。 可以使用
pstack查看 MySQL 进程的堆栈信息。pstack <pid>如果看到类似下面的堆栈信息：
Thread 1 (Thread 0x7f1c9d9e7700 (LWP 1234)): #0 0x00007f1c9c9a6e80 in futex_wait_cancelable (private=0, expected=0, futex_word=0x55f199a4b2f8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 pthread_mutex_lock () from /lib64/libpthread.so.0 #2 lock_table (thd=0x55f198d65700, table=0x55f199a4b200, lock_type=TL_WRITE) at /path/to/mysql/lock.cc:123 #3 mysql_lock_tables (thd=0x55f198d65700, count=1, tables=0x7ffd4b433000) at /path/to/mysql/sql/lock.cc:456 ...这表明该线程正在等待一个互斥锁 (mutex)。
futex_wait_cancelable函数是等待互斥锁的函数。lock_table和mysql_lock_tables函数是加锁的函数。 这提示我们可能存在死锁。为了进一步分析死锁的原因，可以使用
gdb附加到 MySQL 进程，查看线程的状态。gdb /usr/sbin/mysqld <pid>在
gdb界面中，可以使用info threads命令查看所有线程的状态。 找到正在等待互斥锁的线程，并使用bt命令查看其堆栈信息。 同时，查看其他线程的堆栈信息，找到持有该互斥锁的线程。 通过分析这两个线程的堆栈信息，可以找到死锁的原因。例如，线程 A 正在等待线程 B 持有的互斥锁，而线程 B 正在等待线程 A 持有的互斥锁，这就形成了死锁。
解决死锁的方法包括：
- 优化 SQL 语句，减少锁的持有时间。
- 调整事务隔离级别，避免不必要的锁。
- 使用更细粒度的锁。
- 避免循环依赖。
- 设置
innodb_lock_wait_timeout参数，当等待锁的时间超过该参数时，MySQL 会自动回滚事务，避免死锁。
-
案例二：内存泄漏导致 MySQL 进程崩溃
假设 MySQL 进程因为内存泄漏而崩溃，可以使用
gdb加载 Core Dump 文件进行调试。gdb /usr/sbin/mysqld core在
gdb界面中，使用bt命令查看崩溃时的堆栈信息。 如果看到类似下面的堆栈信息：#0 0x00007f1c9c9b2428 in malloc () from /lib64/libc.so.6 #1 0x0000000000e5a321 in my_malloc (size=1024) at /path/to/mysql/memory.cc:123 #2 create_new_thread (thd=0x55f198d65700) at /path/to/mysql/thread.cc:456 ...这表明该线程正在分配内存。
malloc函数是分配内存的函数。my_malloc函数是 MySQL 自定义的内存分配函数。create_new_thread函数是创建新线程的函数。 这提示我们可能存在内存泄漏。为了进一步分析内存泄漏的原因，可以使用
valgrind工具检测 MySQL 进程的内存使用情况。valgrind是一个强大的内存调试工具，可以用来检测内存泄漏、内存越界、使用未初始化的内存等问题。valgrind --leak-check=full /usr/sbin/mysqldvalgrind会输出详细的内存使用报告，包括内存泄漏的位置、大小等信息。 根据valgrind的报告，可以找到内存泄漏的代码，并进行修复。解决内存泄漏的方法包括：
- 检查代码中是否存在未释放的内存。
- 使用智能指针，自动管理内存。
- 使用内存池，减少内存分配和释放的次数。
- 使用
valgrind等工具检测内存使用情况。
-
案例三：错误配置导致 MySQL 进程无法启动
假设 MySQL 进程因为错误配置而无法启动，可以使用
gdb调试启动过程。gdb /usr/sbin/mysqld在
gdb界面中，使用break main命令在main函数入口设置断点，然后使用run命令启动 MySQL 进程。(gdb) break main (gdb) run程序会在
main函数入口处停下来。 可以使用next命令单步执行，逐步调试启动过程。 可以使用print命令查看变量的值，分析配置文件的读取、解析过程。例如，如果配置文件中存在语法错误，
gdb会在解析配置文件的地方停下来，并显示错误信息。解决配置错误的方法包括：
- 仔细检查配置文件，确保语法正确。
- 查看 MySQL 的错误日志，了解启动失败的原因。
- 使用默认配置文件，逐步修改配置，找到导致启动失败的配置项。
第四部分：注意事项和最佳实践
-
使用 Debug 版本:
为了更好地调试 MySQL 进程，建议使用 Debug 版本的 MySQL。 Debug 版本包含了更多的调试信息，可以提供更详细的堆栈跟踪。
-
保留符号表:
不要 strip MySQL 的可执行文件和库文件，保留符号表，可以提供更详细的函数名和文件名信息。
-
使用 Core Dump 文件进行离线调试:
在生产环境中，不建议直接附加到运行中的 MySQL 进程进行调试，可能会影响服务可用性。 建议使用 Core Dump 文件进行离线调试。
-
结合日志分析:
堆栈跟踪只是故障诊断的一种手段，还需要结合 MySQL 的错误日志、慢查询日志等信息，进行综合分析。
-
权限问题:
在使用
pstack和gdb调试 MySQL 进程时，需要具有足够的权限。 通常需要使用 root 用户或者具有 sudo 权限的用户。
第五部分：工具表格对比
| 工具 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
pstack |
简单易用，无需配置，可以快速打印进程的堆栈信息。 | 只能提供简单的堆栈信息，无法进行交互式调试，无法查看变量的值。如果 MySQL 进程被 strip 过，输出的信息会比较有限。 | 快速查看进程的堆栈信息，初步判断问题。 |
gdb |
功能强大，可以进行交互式调试，查看变量的值，设置断点，单步执行等。可以加载 Core Dump 文件进行离线调试。 | 使用复杂，需要一定的调试经验。附加到运行中的进程可能会影响服务可用性。 | 复杂问题的诊断，例如死锁、内存泄漏等。调试启动过程，分析配置文件。 |
最后，一些思考
掌握 pstack 和 gdb 是每个 MySQL DBA 和开发人员的必备技能。 熟练运用这些工具，可以帮助我们快速定位和解决 MySQL 进程的故障，保障数据库的稳定运行。理解堆栈信息、熟练运用调试命令、结合日志分析，可以更有效地进行故障诊断。