mysql运维管理（八）：合格的运维管理员必须掌握的常用工具

在MySQL日常运维工作中，经常会用到各种管理工具，这些工具属于mysql自带的管理工具，存储在mysql目录下的bin目录中，例如对象查看，备份，日志分析等，熟练使用是运维开发人员的必备工作，这些工具参数很多，这里介绍常用选项，更多详细可参考帮助文件。

在mysql工具集中，管理员使用最频繁的就是mysql命令了，它是连接数据库的客户端工具，类似oracle中的sqlplus，通过它可以进入mysql控制台界面。在大部分情况下，使用简单，命令语法如下：

常用选项：选项一般有两种表达方式，一种是"-"+选项单词缩写和选项值；另一种是“--”+选项的完整单词“=”选项实际值。例如我们连接数据库的两种命令如下：

myisampack是一个表压缩工具，它对MyISAM存储引擎表能进行高度压缩，可以很大的节省磁盘空间，但是压缩后的表只能读，不能写，不能进行DML *** 作，所以它的使用场景一般是归档 历史 数据。命令如下：

当对一个压缩表进行增加 *** 作时会报一个错误：ERROR 1036 Table is read only,但时对查询和统计时可以正常 *** 作的。

mysqladmin是一个对数据库进行管理 *** 作的客户端工具，可用来检查服务器是否可用、显示数据库版本号和状态，还可以直接新增一个数据库，也可对数据库进行关闭，功能和mysql类似，它的参数和mysql差异不大，命令如下：

它还可以修改root密码，命令如下

MySQL自带的mysqlbinlog工具的作用是解析二进制binlog的日志内容，把二进制数据还原成mysql可以执行的SQL语句。我有篇文章专门介绍该工具的使用，请具体参考：

传送门：mysql运维管理（七）：使用Mysqlbinlog工具恢复增量数据

mysqlcheck工具可以用来检查和修复MyISAM存储引擎的表,还能做优化的工作，例如check、repair、analyze、optimize等等功能。具体命令如下：

注意，如果是innodb引擎的表，不能用上述优化工具。

mysqldump工具用来逻辑备份数据库，或者数据迁移。该工具是最常用的备份工具。

我有篇文章专门介绍该工具的使用，请具体参考：

传送门：mysql运维管理（五）：掌握MySQLdump逻辑备份工具使用

它是数据导入工具，专门用来处理mysqldump 加-T选项后导出的文本文件，基本用法很简单，命令如下：

客户端对象查找工具，用来查找数据库，数据库的表，表中列或者索引，具体使用命令如下:

不加任何选项，默认显示所有数据库。

常用参数：

--count ,用来显示数据库和表的统计信息，不指定数据库的话，显示所有库信息

-k或者--keys，用来显示指定表中所有索引，例如查看employees库中employees表的索引信息，

在使用mysql使用过程中，会经常出现错误，错误信息都会带有一个编码，具体编码代表什么意思，就需要perror来查看。用法很简单：

举个例子，我们故意写错一个查询语句，例如：

现在有一个编码1054，我们可以用perror查看下

结果跟用工具显示的内容差不多，当然第三方工具也会显示错误信息。

本章做了一个常用工具的使用汇总，并举例说明了基本用法，熟练使用是每个运维人员必修内容，当然还有很多参数没有一一列举，可以参考相关帮助文档。

云时代，最好用的MySQL客户端工具推荐

MySQL是当今最受欢迎的关系型数据库。使用图形客户端（GUI）工具，可以大大帮助开发者提升SQL编写与SQL开发的效率。在云时代，企业越来越多的开始采用RDS MySQL，同时也还有部分本地IDC自建数据库，而在云端也会选择/尝试多个不同云厂商。“工欲善其事，必先利其器”，在这样的背景下，看看有哪些工具产品可供选择吧。

本文完整对比了12种MySQL图形客户端（GUI）工具，从产品体验、功能完整度、云适配、计费模式、OS兼容性等多个角度进行评估与分析，给出推荐。下面产品推荐与整体得分图，读者可根据自己的实际情况选择。

NineData：

是一款非常有特色的数据库SQL开发产品，对MySQL常用功能支持非常完整，包括智能的SQL补全、SQL执行历史、结果集编辑、数据对比、结构对比、数据迁移与复制等。它采用SaaS架构模式，用户不仅可以免费使用，而且无需下载安装，上手比较简单。NineData产品更新迭代比较敏捷，对于开发者的新需求响应比较迅速。另外，该产品在多云适配上是其重要的强项，支持多种连接和访问云数据库的方式，对阿里云、腾讯云、华为云、AWS等都有比较好的支持。另外，也适配国内比较流行的PolarDB、GaussDB、TDSQL等数据库。对于新用户NineData还会赠送两个示例数据库，供用户使用。另外，NineData还提供了企业级SQL开发能力，支持多用户管理、数据库访问权限控制、变更流程、SQL规范、SQL与 *** 作审计等内容，可以较好的解决企业内多人协作访问数据库的问题。

Navicat：

是一款来自香港的产品，约2000年左右发布，是一个老牌的商业化、闭源数据库管理软件，支持主流的Windows、Mac OS X以及Linux，最近两年开始支持订阅模式，个人使用价格约35美元/月，企业版约69美元/月（参考），国内购买为273元/月，有一定的价格门槛，但其使用体验也还不错，功能也比较完整，包括比较强大的SQL补全、导入导出、结果集编辑、E-R模型、数据对比、结构对比、数据迁移等，但有部分功能仅企业版才具备。Navicat的代码块功能做得比较强，可以非常方便自定义一些自己常用的SQL模板。

Workbench：

是最老牌的数据库管理工具了。最早由奥地利程序员Michael G. Zinner独立开发，之后Zinner于2003年加入了MySQL AB公司，并于2005年发布了最早的Workbench 5.0版本；2013年发布了，6.0版本；2018年，发布了8.0版本。整体上，该产品依旧随着MySQL的版本而持续更新，但是，更新节奏较慢，界面也非常“老”，并没有受到Oracle/MySQL的重视。Workbench支持主流的Windows、Mac OS X以及Linux，并且开放源代码。但因为界面架构比较长时间没有更新，所以使用的交互体验一般。因为是MySQL官方工具，功能支持是比较完整的，包括SQL补全、SQL历史、导入导出、结果集编辑、E-R模型、数据对比、结构对比、数据迁移等功能都具备。另外，也提供商业化的企业版，支持部分MySQL企业版的功能。

DBeaver：

是一个基于 Java 开发数据库管理工具，提供开源免费的版本。因为是基于Java的，所以也能够支持Windows、Linux、macOS 等 *** 作系统，其支持的数据库类型也比较多。同时也是因为基于Java，其在访问的不同的数据库版本时，有时候需要在线做一些驱动更新，需要访问GitHub的一些资源，而因为一些原因，这类更新经常失败，使其使用体验有一定打折。DBeaver也提供了基础的SQL补全、导入导出、结果集编辑等功能，但也有部分功能仅限于企业版（Pro版本）才提供，另外，软件似乎因为比较大的缘故，所以运行起来有点慢。

phpMyAdmin：

这是另一个老牌的开源免费MySQL访问工具了，在云时代之前，开发者经常需要自己搭建自己完整的开发环境（例如“LAMP”）时，该软件还比较流行。从名字可以看出来，这是一个PHP的Web-Based的MySQL访问工具，所以需要使用并不是很方便，需要构建自己的Web服务器和PHP运行环境。一般来说，现在的开发者也并不会这么去做。另外，phpMyAdmin一直没有商业化，主要靠捐赠和赞助的方式在运转（参考，有意思的是Navicat也在赞助列表，而且是唯一的白金赞助商），整体上，phpMyAdmin其迭代速度非常慢，功能支持也很有限，但是如果是简单、基础的使用，是没有问题的。但，如果是日常开发使用，并不是很推荐。

dbForge：

dbForge是devart的核心产品，最早主要是支持SQL Server数据库，最近几年也发布了对MySQL数据库的支持，也是一个商业化收费软件，产品可以下载试用一段时间。根据使用经验来看，体验还是非常不错的，功能也非常完整。但是，仅支持Windows版本，标准版费用为199美元/年，起步价也并不便宜。

SQLYOG：

SQLyog更多的是专注于数据库的管理，包括性能、监控、优化等方面，也提供基础SQL编辑功能，所以在早期，其在DBA群体中比较受欢迎，但是在整体的开发者中，使用比率并不高。虽然，提供开源的社区版本，但是当前，公司主要在推广其商业版本。另外，在云时代对于监控与实例管理方面的诉求在降低，在SQL开发与云适配上需求更强。从这个角度来看，并不是很推荐这个这个产品。此外，该软件仅支持Windows系统。最近几年这个产品发展比较缓慢，而且SQL开发功能也不再是主推的功能，所以也并不是特别推荐。

HeidiSQL：

HeidiSQL也是一个发展了很长时间的MySQL客户端，使用Delphi构建，所以整体上，有非常好的Windows使用体验。但是不能支持macOS或者Linux。因为发展时间比较长，功能也比较完整。新增了部分对于云产品的适配，例如，如果类型选择的是AWS RDS，那么在kill连接的时候会使用特定的存储过程进行kill。

阿里云DMS：

因为阿里云在国内市占率非常高，所以，阿里云DMS也是一个使用比较广，但是也因为其为阿里云的产品，所以其作为MySQL管理工具并不是非常有名。DMS比较完整的支持MySQL日常SQL开发相关的工作，其功能矩阵也比较完整，可以完成日常的开发工作。DMS对于阿里云数据库的适配自然是非常好，使用也比较便利。但，其对于其他云数据库（诸如腾讯、华为、AWS）的支持就比较有限，而且似乎也并不会在这方面做任何的投入。另外，DMS最近一年的产品大方向主要是在于"一站式的数据管理"，所以新增了数据资产、数据开发任务编排等功能。不再是一个SQL开发工具。

BeeKeeper Studio：

Beekeeper目前是由一个由个人开发的MySQL GUI软件。界面简洁现代，支持比较基础的SQL开发功能，包括了SQL窗口、创建表等能力，同时有非常好的平台兼容性。向用户提供免费的功能有限的社区版，完整版是收费的，最低价格为19美元。

DbVisualizer：

DbVisualizer发展时间也比较长了，支持的数据库种类也非常多，底层是基于Java构建的，有不错的平台兼容性，支持Windows / Linux / macOS，在市场也获得不错认可。不过，该软件仅支持英语，并没有对应的中文支持。

小结

通过Wine等方式支持的OS平台，这里并没有考虑，因为根据经验来看，大多数情况下，稳定性都不太好。另外，市面上也还有一些产品超过两年未更新，这里就不再介绍了，例如MyDB Studio；也有部分软件平台属性太强，例如Sequel Pro仅支持Mac，这里也没有介绍。总体上，打分有较强的主观性，所以仅供参考。

下面我们就看一下常见的备份工具，以及目前最流行的 Percona XtraBackup 的备份流程。

MySQL 常见的备份工具主要分为三种：

这里先说一下 binlog 备份，它只是把 binlog 又复制了一份，并且需要在逻辑备份或者物理备份的基础上才能进行数据恢复，无法单独进行数据恢复。

mysqldump 备份出的文件就是 sql 文件，其核心就是对每个表执行 select ，然后转化成相应的 insert 语句。mysqldump 的备份流程大致如下：

从上面可以看出在 mysqldump 备份期间，备份到某个数据库时，该数据库下的表都会处于只读状态，无法对表进行任何变更，直到该库下的表备份完毕，这对于线上环境一般是无法接受的。若是指定了--master-data或者 --dump-slave 则会在备份开始时加全局读锁（FLUSH TABLES WITH READ LOCK），直到备份结束。当然我们可以选一个从库进行备份，这样就不会影响线上业务。另外使用 mysqldump 备份还有一个最大的好处，因为备份出来的是 sql 语句，所以它支持跨平台和跨版本的数据迁移或者恢复，这是物理备份无法做到的。

但是也正是因为 mysqldump 备份出来的是 sql 语句，在使用时要更加注意，否则可能会酿成大祸。例如，使用 mysqldump 常见的问题有：

所以使用 mysqldump 时一定要了解各个选项的作用，以及确认备份出来的 sql 文件里会有什么 *** 作，会对现有数据造成什么影响。

Mydumper 原理与 Mysqldump 原理类似，最大的区别是引入了多线程备份，每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的。这里不再单独介绍。

Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，是基于 InnoDB 的崩溃恢复功能来实现的。它的基本工作原理如下：

Percona XtraBackup 在进行恢复时会应用拷贝的 redo log ，应用已提交的事务，回滚未提交的事物，将数据库恢复到一致性状态。因为 Percona XtraBackup 备份出来的是物理文件，所以在使用备份出的文件进行恢复或者迁移时，不会像 mysqldump 那样会存在很多问题。

使用 XtraBackup 备份时根据备份参数设置不同，对数据库的变更会造成不同程度的影响，具体影响会在下文分析。

通过对比发现，XtraBackup 具有对数据库影响小，且能快速恢复的优点，在日常备份中是首选；mysqldump 使用相对更加灵活，但是使用是要注意对数据库原有数据的影响。

备份策略主要有：全量备份和增量备份，再加上 binlog 备份。

目前去哪儿网数据库备份主要采用 XtraBackup 全量备份 +binlog 备份。数据库的重要级别不同，全量备份的频率不同。备份程序主要架构如下：

说明：

Percona XtraBackup 是目前备份 MySQL 使用最广泛的工具。在备份过程中，数据库可以进行正常的读写或者其他变更 *** 作，但是偶尔也会遇见备份引起的元数据锁，或提交事务时发现被 binlog lock 阻塞等情况。下面我们就看一下 Percona XtraBackup 的备份流程和加锁时机。

说明：以下对 Percona XtraBackup 的分析都是基于 2.4.23 的版本，其他版本会略有差别，但是关键步骤基本相同。

XtraBackup 在备份开始时，会创建一个后台线程，专门用于拷贝数据库的 redo log 。首先 XtraBackup 会扫描每组 redo log 的头部，找出当前的 checkpoint lsn ，然后从该 lsn 后顺序拷贝所有的 redo log ，包括后续新产生的 redo log 。该线程会一直持续到将非事务表完全拷贝完成，才会安全退出。备份日志输出中会记录拷贝开始时的 checkpoint lsn 。日志输出如下：

在拷贝ibd文件之前，会先扫描数据库的数据文件目录，获取ibdata1，undo tablespaces及所有的ibd文件列表，并会记录相应的 space id，因为在恢复时需要这些 space id来找到对应 doublewrite buffer里页面的内容，以及对应的redo log条目。然后开始循环拷贝ibdata1，undo tablespaces及所有的ibd文件。

这里可通过设置--parallel进行多线程备份，提高物理文件的拷贝效率。不设置则默认为1。

在所有ibd文件拷贝完成后，XtraBackup开始备份非ibd文件。这一部分的逻辑比较复杂，因为备份非ibd文件前需要加锁，具体是否会加锁主要受到--no-lock 参数设置的影响。

若是设置了--no-lock为TRUE，则不会使用"FLUSH TABLES WITH READ LOCK"去加全局读锁，但是若备份过程中对non-InnoDB表执行了DDL或者DML *** 作， 这会导致备份的不一致，恢复出来的数据就会有问题。所以是不建议将--no-lock为TRUE，默认值是FALSE，也就是在不指定该选项的情况下会在备份非ibd文件前加全局读锁。

下面我们结合源码来看看判断是否加全局锁这部分的具体流程逻辑：

流程图如下：

总结来看：

1）若--no-lock为FALSE（默认值），则先施加全局读锁，然后再进行拷贝文件，另外若 --safe-slave-backup 设置为TRUE ，则会在加全局锁之前关闭SQL_THREAD线程；

2）若--no-lock为TRUE，则不会施加锁，直接进行拷贝文件。

加锁的逻辑主要由lock_tables_maybe实现,先看一下lock_tables_maybe源代码，如下：

lock_tables_maybe 函数简化处理流程如下：

1）若备份实例上已经加锁（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者设置lock-ddl-per-table 则直接返回；

2）若支持备份锁，则执行LOCK TABLES FOR BACKUP；

3）若不支持备份锁，则执行 FLUSH TABLES WITH READ LOCK。根据相应选项设置，在执行该 *** 作前会判断是否有执行中的DDL/DML，以及等待超时时间，是否kill 对应的未结束的事务等。

从上文中我们还看到一个参数--safe-slave-backup ，该参数的主要作用是：

若是在从库执行的备份 *** 作时设置了该参数，可以防止因从库同步主库 *** 作，而导致XtraBackup长时间请求不到锁而造成备份失败。

若是设置了 --safe-slave-backup 为TRUE，那么会执行"STOP SLAVE SQL_THREAD"，并等待Slave_open_temp_tables 为零才开始拷贝非 ibd 文件，Slave_open_temp_tables 为零说明SQL thread执行的事务都已经完成，这样就能保证备份的一致性。并且此时也不会有在执行的事务阻塞 XtraBackup 施加全局锁。

备份完非 ibd 文件后，将会备份 slave 和 binlog 信息。

mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1

需要注意，在支持备份锁的实例上备份，指定了 --slave-info 或--binlog-info 均会先施加 binlog 备份锁（ LOCK BINLOG FOR BACKUP），这会阻塞任何会更改 binlog 位点的 *** 作。

备份完数据库的所有文件和binlog等相关信息，备份工作就基本完成了，之后主要执行的 *** 作如下：

1）执行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",将所有的redo log刷盘；

2）停止redo log复制线程；

3）释放全局读锁（备份锁），binlog锁；

4）开启SQL_THREAD；

5）拷贝ib_buffer_pool和ib_lru_dump文件；

6）生成配置文件backup-my.cnf；

7）打印备份信息到xtrabackup_info文件，这些信息主要包含备份时使用的参数信息，备份起止时间，binlog位点信息，以及将会回到的lsn点。

下面是xtrabackup_info记录的部分内容：

加锁对应的函数是 mdl_lock_tables ，释放锁对应的函数是 mdl_unlock_all，主要是执行COMMIT，结束 mdl_lock_tables 中开启的显式事务，来释放MDL锁。mdl_lock_tables 流程如下：

上面参数--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之后添加的，因为 MySQL 5.7 新增了一个叫做 Sorted Index Builds 的功能，这会导致某些 DDL *** 作不记录重做日志而导致备份失败。使用--lock-ddl或--lock-ddl-per-table 就会在备份开始时施加锁，阻止 DDL *** 作。

另外，若备份时指定了--lock-ddl或--lock-ddl-per-table，则在备份非 ibd 文件时就不是再有加锁 *** 作。

注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 语句只有在支持备份锁的实例上才会执行，Percona Server for MySQL已经在 5.6.16-64.0 版本开始支持这种更加轻量的备份锁。

Q1: 使用 XtraBackup 备份的文件进行恢复时，恢复到哪个时间点？ A1：恢复到执行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的时间点，因为这时任何改变 binlog 位点的 *** 作都会被阻塞，redo log和binlog 是一致的。

Q2: 在开启 binlog 的情况下，MySQL 的奔溃恢复是同时依赖 binlog 和 redo log 这两种日志的，为什么XtraBackup 不用备份binlog？

A2：因为在备份中有执行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改变binlog位点的 *** 作，这样只需要根据redo log将有commit log 的事务提交，没有commit log的事务进行回滚即可。

Q3: 使用Percona XtraBackup备份完成后redo的位点是和binlog是一样还是比binlog多一些？

A3：通过分析备份流程可以发现备份 binlog 位点信息（加binlog锁）是发生在停止 redo 拷贝线程前，而释放锁是在停止 redo 拷贝线之后，所以 redo log 会多一些。锁住了 binlog 保证了在该 binlog 位点前已经提交的事务的 redo log 都有 commit log 的信息，未提交的事物也就没有对应的 commit log 的信息，即便在锁住 binlog 后有 Innodb 表新的 DML 产生的 redo log ，但是事务无法提交，也就没有 commit log 的信息的，最后在回放的过程中对没有 commit log 的事务进行回滚就可以了。

Q4：Percona XtraBackup什么时候会加锁，以及影响加锁时间长度的因素有哪些？

A4：上面进行了分析，加锁 *** 作只在备份非 ibd 文件时执行，加锁时长主要和非事务表的数量和大小有关，非事务表的数量越多，体积越大，拷贝文件所用的时间越长，那么加锁时间也就越长。也会和 redo log 生成的速度有关，只是 redo log 刷盘受到多个因素的影响，未及时刷盘的 redo log 一般很小。

Q5：Percona XtraBackup 和mysqldump选择哪个更好？

A5：通过上面的的解析，若是整个实例备份，首先选择 Percona XtraBackup ，因为对数据库的影响最小。若只是备份某个库表，这个就要视数据量而定，若数据量不大可以使用 mysqldump 。注意，对数据库做备份时最好选择业务连接最少的从库，因为备份也会消耗一定的资源，避免影响业务。

---