[深入理解MySQL系列] - mysqldump的几个主要选项探究
0、前言
本文主要探讨 mysqldump 的几种主要工作方式,并且比较一下和 mk-parralel-dump 的一些差异,为备份方式的选择提供更多的帮助。
1、mysqldump
首先来看下 mysqldump 的几个主要参数的实际工作方式。
mysqldump 几个主要选项
1. -q
很简单,什么都不做,只是导出时加了一个 SQL_NO_CACHE 来确保不会读取缓存里的数据。
081022 17:39:33 7 Connect root@localhost on
7 Query /*!40100 SET @@SQL_MODE='' */
7 Init DB yejr
7 Query SHOW TABLES LIKE 'yejr'
7 Query LOCK TABLES `yejr` READ /*!32311 LOCAL */
7 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1
7 Query show create table `yejr`
7 Query show fields from `yejr`
7 Query show table status like 'yejr'
7 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
7 Query UNLOCK TABLES
7 Quit
2. --lock-tables
跟上面类似,不过多加了一个 READ LOCAL LOCK,该锁不会阻止读,也不会阻止新的数据插入。
081022 17:36:21 5 Connect root@localhost on 5 Query /*!40100 SET @@SQL_MODE='' */ 5 Init DB yejr 5 Query SHOW TABLES LIKE 'yejr' 5 Query LOCK TABLES `yejr` READ /*!32311 LOCAL */ 5 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 5 Query show create table `yejr` 5 Query show fields from `yejr` 5 Query show table status like 'yejr' 5 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 5 Query UNLOCK TABLES 5 Quit
3. --lock-all-tables
这个就有点不太一样了,它请求发起一个全局的读锁,会阻止对所有表的写入操作,以此来确保数据的一致性。备份完成后,该会话断开,会自动解锁。
081022 17:36:55 6 Connect root@localhost on 6 Query /*!40100 SET @@SQL_MODE='' */ 6 Query FLUSH TABLES 6 Query FLUSH TABLES WITH READ LOCK 6 Init DB yejr 6 Query SHOW TABLES LIKE 'yejr' 6 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 6 Query show create table `yejr` 6 Query show fields from `yejr` 6 Query show table status like 'yejr' 6 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 6 Quit
4. --master-data
除了和刚才的 --lock-all-tables 多了个 SHOW MASTER STATUS 之外,没有别的变化。
081022 17:59:02 1 Connect root@localhost on 1 Query /*!40100 SET @@SQL_MODE='' */ 1 Query FLUSH TABLES 1 Query FLUSH TABLES WITH READ LOCK 1 Query SHOW MASTER STATUS 1 Init DB yejr 1 Query SHOW TABLES LIKE 'yejr' 1 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 1 Query show create table `yejr` 1 Query show fields from `yejr` 1 Query show table status like 'yejr' 1 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 1 Quit
5. --single-transaction
InnoDB 表在备份时,通常启用选项 --single-transaction 来保证备份的一致性,实际上它的工作原理是设定本次会话的隔离级别为:REPEATABLE READ,以确保本次会话(dump)时,不会看到其他会话已经提交了的数据。
081022 17:23:35 1 Connect root@localhost on 1 Query /*!40100 SET @@SQL_MODE='' */ 1 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 1 Query BEGIN 1 Query UNLOCK TABLES 1 Init DB yejr 1 Query SHOW TABLES LIKE 'yejr' 1 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 1 Query show create table `yejr` 1 Query show fields from `yejr` 1 Query show table status like 'yejr' 1 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 1 Quit
6. --single-transaction and --master-data
本例中,由于增加了选项 --master-data,因此还需要提交一个快速的全局读锁。在这里,可以看到和上面的不同之处在于少了发起 BEGIN 来显式声明事务的开始。这里采用 START TRANSACTION WITH CONSISTENT SNAPSHOT 来代替 BEGIN 的做法的缘故不是太了解,可以看看源代码来分析下。
081022 17:27:07 2 Connect root@localhost on 2 Query /*!40100 SET @@SQL_MODE='' */ 2 Query FLUSH TABLES 2 Query FLUSH TABLES WITH READ LOCK 2 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 2 Query START TRANSACTION WITH CONSISTENT SNAPSHOT 2 Query SHOW MASTER STATUS 2 Query UNLOCK TABLES 2 Init DB yejr 2 Query SHOW TABLES LIKE 'yejr' 2 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 2 Query show create table `yejr` 2 Query show fields from `yejr` 2 Query show table status like 'yejr' 2 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 2 Quit
关于隔离级别可以看手册 13.2.10.3. InnoDB and TRANSACTION ISOLATION LEVEL,或者本站之前的文章:[InnoDB系列] - 实例解析Innodb的隔离级别以及锁模式。
关于 START TRANSACTION WITH CONSISTENT SNAPSHOT 的说明可以看下手册描述:
The WITH CONSISTENT SNAPSHOT clause starts a consistent read for storage engines that are capable of it. This applies only to InnoDB. The effect is the same as issuing a START TRANSACTION followed by a SELECT from any InnoDB table. See Section 13.2.10.4, “Consistent Non-Locking Read”. The WITH CONSISTENT SNAPSHOT clause does not change the current transaction isolation level, so it provides a consistent snapshot only if the current isolation level is one that allows consistent read (REPEATABLE READ or SERIALIZABLE).
12.4.1. START TRANSACTION, COMMIT, and ROLLBACK Syntax
2. mysqldump 和 mk-parralel-dump 的比较
mk-parralel-dump 是开源项目 Maatkit 中的一个工具,主要由 Baron Schwartz 维护。
mk-parralel-dump 是由 perl 开发的,可以实现并发的导出数据表。具体的功能不细说,自己去看相关文档吧。这里只列出在我的环境下和 mysqldump 的对比数据。
2.1 mysqldump 常规使用
#导出耗时 time mysqldump -f --single-transaction -B yejr --tables yejr | gzip > /home/databak/yejr.sql.gz real 10m15.319s user 6m47.946s sys 0m38.496s #文件大小 608M /home/databak/yejr.sql.gz #导出期间系统负载 05:00:01 PM all 0.71 0.00 0.61 7.33 91.36 05:10:02 PM all 13.93 0.00 2.21 4.64 79.22
2.2 mysqldump + gzip --fast
#导出耗时 time mysqldump -f --single-transaction -B yejr --tables yejr | gzip --fast > /home/databak/yejr_fast.sql.gz real 9m6.248s user 4m21.467s sys 0m37.604s #文件大小 815M Oct 21 17:33 /home/databak/yejr_fast.sql.gz #导出期间系统负载 05:20:01 PM all 11.94 0.00 2.43 5.69 79.94 05:30:01 PM all 6.46 0.00 1.57 3.95 88.02
2.3 mk-parallel-dump 常规使用
time ./mk-parallel-dump --database yejr --tables yejr --basedir /home/databak/ default: 25 tables, 25 chunks, 25 successes, 0 failures, 404.93 wall-clock time, 613.25 dump time real 6m48.763s user 4m20.724s sys 0m38.125s #文件大小 819M /home/databak/default/yejr/ #导出期间系统负载 05:10:02 PM all 13.93 0.00 2.21 4.64 79.22 05:20:01 PM all 11.94 0.00 2.43 5.69 79.94
可以看到,mk-parallel-dump 尽快确实实现了并发导出,速度相对快多了,却有个致命伤:那就是它不支持InnoDB的一致性备份,目前已经有人提交相关代码了,不过还没实现,期待中。
评论
coolec (未验证)
周六, 2008/11/08 - 11:58
Permalink
你好!请问下 2003的服
你好!请问下
2003的服务器,mysql每次重启后启动的时间超长是什么原因?提示mysql已经启动,但是程序任然无法链接mysql。现在大概需要过20-30分钟才恢复正常。请问有什么解决方法吗?
yejr
周六, 2008/11/08 - 12:18
Permalink
应该是重启时在自动
应该是重启时在自动修复表,贴下日志先
MySQL方案、培训、支持
游客 (未验证)
周日, 2009/04/19 - 12:41
Permalink
请问老大,你的每个
请问老大,你的每个解释 下面的例子是怎么得到的?
例如:
081022 17:23:35 1 Connect root@localhost on
1 Query /*!40100 SET @@SQL_MODE='' */
1 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
1 Query BEGIN
1 Query UNLOCK TABLES
1 Init DB yejr
1 Query SHOW TABLES LIKE 'yejr'
1 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1
1 Query show create table `yejr`
1 Query show fields from `yejr`
1 Query show table status like 'yejr'
1 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
1 Quit
游客 (未验证)
周日, 2009/04/19 - 12:42
Permalink
请问老大,你的每个
请问老大,你的每个解释 下面的例子是怎么得到的?
例如:
081022 17:23:35 1 Connect root@localhost on
1 Query /*!40100 SET @@SQL_MODE='' */
1 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
1 Query BEGIN
1 Query UNLOCK TABLES
1 Init DB yejr
1 Query SHOW TABLES LIKE 'yejr'
1 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1
1 Query show create table `yejr`
1 Query show fields from `yejr`
1 Query show table status like 'yejr'
1 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
1 Quit
沙漠风暴 (未验证)
周二, 2009/06/30 - 15:13
Permalink
Mysql 日志
Mysql 日志
yejr
周二, 2009/06/30 - 15:29
Permalink
嗯,就是所谓的general
嗯,就是所谓的general log,修改 my.cnf,加上一行 log = xxx.log
MySQL方案、培训、支持
问心的方向 (未验证)
周一, 2013/03/04 - 18:43
Permalink
不是很明白--single-transaction and
不是很明白--single-transaction and --master-data 这2个参数一起用的好处在那里。希望博主解惑一下。
yejr
周一, 2013/03/04 - 21:53
Permalink
在启用binlog的场景下,如果需要备份innodb
在启用binlog的场景下,如果需要备份innodb,就需要2个参数一起用才能保证备份数据一致性并且记录当时的binlog信息。
问心的方向 (未验证)
周二, 2013/03/05 - 10:15
Permalink
我可以理解为,--single-transaction
我可以理解为,--single-transaction 是为了保证数据一致性。
而--master-data 是为了记录当时的binlog。
也就是说,用dump出来的备份可以还原。那么以前的binlog 就没用了。。可以不加--master-data吗?
我们游戏是,每天晚上全备一次,然后每小时增量一次。
全备的命令是 mysqldump -u User --flush-logs --delete-master-logs --all-databases > alldb.sql
增量就是mysqladmin flush-logs 刷一下,保存起来。
然后最近看您的博客,提示说innodb的表,最好用--single-transaction ,那么我在加上--flush-logs --delete-master-logs 这2个参数的话,是为了删除全备以前的binlog, 当出现问题。还原最新全备,然后依次还原增量的话,是完全没问题的。 感觉--master-data 就没什么用处了。
还有就是我线上的innodb库备份都没加--single-transaction ,但是备份完在还原的话,也是没什么问题。那么推荐加这个参数的好处,体现在那里?
希望博主解惑一下这2个问题。
1.--master-data 在我这样的环境中有用吗?
2.--single-transaction 和我线上现有的备份方法,该怎么取舍?
对了 mysql版本是:5.5.23-log MySQL Community Server (GPL)
yejr
周二, 2013/03/05 - 23:56
Permalink
single-transaction用以保证备份数据一致性
single-transaction用以保证备份数据一致性。
master-data用以记录binlog位置,一般在这个备份可能用于slave上恢复后部署replication才需要,如果不做这个目的的话,并且将来业务也无需关注这个备份开始对应的binlog的话,可以直接刷新log,用你现在的方式即可。