[译文] MySQL服务器的诊断方法

当服务器宕机时，在我看来，有两个步骤是必不可少的，而且都非常重要，都不应被忽视：

1. 保存用于确定根本原因分析 (RCA) 的诊断信息。
2. 让服务器重新启动并运行。

太多人急于执行第 2 步，而失去了第 1 步的相关诊断信息。同样，太多人会在第 1 步上花费太多时间，而延迟到第 2 步并恢复服务。目标是尽快收集诊断信息以供日后查看，同时尽快恢复服务。

技术资源倾向于在试图了解服务器中断的原因时陷入困境，以至于忘记了停机时间正在浪费业务资金。对于担心在服务恢复时重要诊断数据会丢失的人来说，爬取服务器日志、审查指标、倾倒系统指标等可能十分吸引注意力，但必须有一个中间立场。

相反，许多人，尤其是管理人员，会要求立即恢复服务以继续业务功能。当然，在服务备份之后，对RCA的需求就会来。可悲的是，当服务器被退回时，许多指标和一些日志都会丢失。以下是有关为 MySQL 收集哪些指标的基本指南。这些步骤没有特定的顺序。

1. 保存 MySQL 错误日志的副本。

sudo cp /path/to/datadir/*.log /some/where/safe

2. 复制 MySQL 配置文件。

sudo cp /path/to/my.cnf /some/where/safe

3. 制作系统日志的副本并将它们保存在永久存储中不会被覆盖的位置。考虑在 Linux 上执行以下操作：

sudo cp /var/log/syslog /some/where/safe/syslog
sudo cp /var/log/messages /some/where/safe/messages
sudo journalctl -e > /some/where/safe/journalctl.txt

4. 如果 MySQL 仍在运行并且您可以登录，请获取一些 MySQL 指标。您将希望将输出保存到某处的文件中。

sudo mysqladmin -i10 -c10 proc > /some/where/safe/mysql_procs.txt
mysql> SHOW GLOBAL VARIABLES;
sudo mysqladmin -i10 -c10 ext > /some/where/safe/mysql_ext.txt
mysql> SHOW ENGINE INNODB STATUS\G

5. 如果 MySQL 正在运行并且您有Percona Toolkit，您应该收集一些 pt-stalk 输出。

sudo ./pt-stalk --no-stalk --iterations=2 --sleep=30 --dest=/some/where/safe -- --user=root --password=<mysql-root-pass>;

6. 如果您有空间和时间，一份数据库文件（MySQL 中的数据目录）的副本可能会有所帮助。当然，对于许多安装，获取所有数据文件是不可能的。如果它是一个小型数据库并且空间和时间允许，最好获取所有文件以防万一。

sudo cp -R /path/to/datadir /some/where/safe/datadir

7. 复制数据库日志并将它们保存在安全的地方供以后查看。像系统的Percona XtraDB集群（PXC）将可以真正的帮助来看看，以确定问题的根源问题过程中创建GRA文件。通过将 GRA 头文件与 GRA 日志文件的内容结合，您可以使用 mysqlbinlog 命令来获取导致问题的事务记录。

sudo cp /path/to/data/dir/GRA* /some/where/safe/datadir/

8. 保存与 CPU、I/O 和内存使用相关的系统指标：

sudo mpstat -a 1 60 > /some/where/safe/mpstat.txt
sudo vmstat 1 60 > /some/where/safe/vmstat.txt
sudo iostat -dmx 1 60 > /some/where/safe/iostat.txt

9. 保存系统信息。

sudo cat /proc/cpuinfo > /some/where/safe/cpuinfo.txt

10. 如果您有 Percona Toolkit，以下内容将非常有帮助：

sudo pt-summary > /some/where/safe/pt-summary.txt
sudo pt-mysql-summary > /some/where/safe/pt-mysql-summary.txt

11. 获取硬件诊断。

# disk info
sudo df -k > /some/where/safe/df_k.txt
sudo lsblk -o KNAME,SCHED,SIZE,TYPE,ROTA > /some/where/safe/lsblk.txt
sudo lsblk --all > $PTDEST/lsblk-all;
 
# lv/pv/vg only for systems with LVM
sudo lvdisplay --all --maps > /some/where/safe/lvdisplau-all-maps.txt
sudo pvdisplay --maps > /some/where/safe/pvdisplay-maps.txt
sudo pvs -v > /some/where/safe/pvs_v.txt
sudo vgdisplay > /some/where/safe/vgdisplay.txt
 
# nfsstat for systems with NFS mounts 
sudo nfsstat -m > /some/where/safe/nfsstat_m.txt
sudo nfsiostat 1 120 > /some/where/safe/nfsiostat.txt
 
# Collect hardware information 
sudo dmesg > /some/where/safe/dmesg.txt
sudo dmesg -T free -m > /some/where/safe/dmesg_free.txt 
sudo dmesg -T > /some/where/safe/dmesg_t.txt
sudo ulimit -a > /some/where/safe/ulimit_a.txt
sudo cat /proc/sys/vm/swappiness > /some/where/safe/swappiness 
sudo numactl --hardware > /some/where/safe/numactl-hardware.txt

最好将上述内容编写成一个有用的 bash 脚本，可以在出现问题时运行。请务必在出现问题之前测试脚本。

同样，目标是保留有用的诊断数据，这些数据可能有助于在服务恢复后稍后确定问题的根本原因。只是不要沉迷于查看上述诊断程序！当然，更多的数据更好，但以上是一个基础。随着时间的推移，你可能会希望拥有其他指标，并且可以将它们添加到脚本或标准操作程序 (SOP) 中。