MySQL官方导出工具mysqlpump的使用


Posted in MySQL onMay 21, 2021

简介

mysqlpump 是 mysqldump 的一个衍生,本身也参考了 mydumper 的思路,支持了并行导出数据,因此导出数据的效率比 mysqldump 会高很多。

使用介绍

mysqlpump 的绝大多数参数与 mysqldump 是一样的,整体的使用方法和 mysqldump 没有太多的差异。这里列出一部分 mysqlpump 中比较重要且常用的参数。

 

参数

说明

--default-parallelism=#

设置并行导出的并发度,与 single-transaction 冲突

--single-transaction

创建一个单独的事务来导出所有的表

--exclude-databases=name

导出时排除掉某些库,多个库以逗号分隔

--exclude-tables=name

导出时排除掉某些表,多个表以逗号分隔

--include-databases=name

导出时包含某些库,多个库以逗号分隔

--include-tables=name

导出时包含某些表,多个表以逗号分隔

实际体验

这里对 mysqlpump 做一次简单的试用,目标实例选择 MySQL 5.7,参数中同时采用了single-transaction和default-parallelism,试试看这个冲突的效果。

mysqlpump 侧的输出参考如下信息:

root@VM-64-10-debian:~# mysqlpump -h172.100.10.10 -uroot -p --single-transaction --default-parallelism=16 --set-gtid-purged=OFF -B sbtest > sbtest.sql
Dump progress: 0/1 tables, 250/987400 rows
Dump progress: 0/5 tables, 117250/3946600 rows
Dump progress: 1/5 tables, 258750/3946600 rows
Dump progress: 1/5 tables, 385500/3946600 rows
Dump progress: 1/5 tables, 516750/3946600 rows
Dump progress: 1/5 tables, 639250/3946600 rows
Dump progress: 1/5 tables, 757000/3946600 rows
Dump progress: 1/5 tables, 885000/3946600 rows
Dump progress: 1/5 tables, 1005750/3946600 rows
Dump progress: 1/5 tables, 1114250/3946600 rows
Dump progress: 1/5 tables, 1223250/3946600 rows
Dump progress: 2/5 tables, 1312500/3946600 rows
Dump progress: 2/5 tables, 1430750/3946600 rows
Dump progress: 2/5 tables, 1553000/3946600 rows
Dump progress: 2/5 tables, 1680250/3946600 rows
Dump progress: 2/5 tables, 1809500/3946600 rows
Dump progress: 2/5 tables, 1940750/3946600 rows
Dump progress: 2/5 tables, 2060000/3946600 rows
Dump progress: 2/5 tables, 2175250/3946600 rows
Dump progress: 2/5 tables, 2295250/3946600 rows
Dump progress: 3/5 tables, 2413500/3946600 rows
Dump progress: 3/5 tables, 2554500/3946600 rows
Dump progress: 3/5 tables, 2693500/3946600 rows
Dump progress: 3/5 tables, 2818750/3946600 rows
Dump progress: 3/5 tables, 2941500/3946600 rows
Dump progress: 4/5 tables, 3056000/3946600 rows
Dump progress: 4/5 tables, 3172750/3946600 rows
Dump progress: 4/5 tables, 3280000/3946600 rows
Dump progress: 4/5 tables, 3372000/3946600 rows
Dump progress: 4/5 tables, 3444750/3946600 rows
Dump completed in 126555 milliseconds

可以看到当这两个参数同时启用的时候,mysqlpump 实际上还是在一个一个表的导出。single-transaction的优先级会高于default-parallelism。

去掉single-transaction再进行测试的时候,会发现一个比较有意思的现象,观察 MySQL 的 processlist,会有如下结果:

mysql> show processlist;
+---------+------+--------------------+------+---------+------+-------------------+----------------------------------------------------+
| Id      | User | Host               | db   | Command | Time | State             | Info                                               |
+---------+------+--------------------+------+---------+------+-------------------+----------------------------------------------------+
| 2763496 | root | 172.100.10.10:49086 | NULL | Query   |    0 | starting          | show processlist                                   |
| 2763585 | root | 172.100.10.10:49192 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763586 | root | 172.100.10.10:49194 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763587 | root |172.100.10.10:49196 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763588 | root | 172.100.10.10:49198 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763589 | root | 172.100.10.10:49200 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763590 | root | 172.100.10.10:49202 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763591 | root | 172.100.10.10:49204 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763592 | root | 172.100.10.10:49206 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763593 | root | 172.100.10.10:49208 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763594 | root | 172.100.10.10:49210 | NULL | Sleep   |  126 |                   | NULL                                               |
| 2763595 | root | 172.100.10.10:49212 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest5` |
| 2763596 | root | 172.100.10.10:49214 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest4` |
| 2763597 | root | 172.100.10.10:49216 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest3` |
| 2763598 | root | 172.100.10.10:49218 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest2` |
| 2763599 | root | 172.100.10.10:49220 | NULL | Query   |  125 | Sending to client | SELECT `id`,`k`,`c`,`pad`  FROM `sbtest`.`sbtest1` |
| 2763600 | root | 172.100.10.10:49222 | NULL | Sleep   |  125 |                   | NULL                                               |
| 2763601 | root | 172.100.10.10:49224 | NULL | Sleep   |  125 |                   | NULL                                               |
+---------+------+--------------------+------+---------+------+-------------------+----------------------------------------------------+
18 rows in set (0.00 sec)

mysql>

可以很明显的看出来,mysqlpump 的“并行导出”实际上只是基于表级别的并行导出,当存在单个大表的时候,导出的时间会被严重的影响,存在短板效应。

额外的疑问:如果default-parallelism和single-transaction有冲突的话,那么并行导出的时候是不是无法确认数据一致性?

实践出真实,打开 general_log 看一下导出时的操作:

2021-05-12T11:54:09.033215Z        75 Connect   root@172.100.10.10 on  using SSL/TLS
2021-05-12T11:54:09.075347Z        75 Query     FLUSH TABLES WITH READ LOCK //开始锁表
2021-05-12T11:54:09.103132Z        75 Query     SHOW WARNINGS
2021-05-12T11:54:09.106382Z        75 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:09.106553Z        75 Query     SHOW WARNINGS
2021-05-12T11:54:09.106640Z        75 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:09.108115Z        75 Query     SHOW WARNINGS
2021-05-12T11:54:09.127277Z        76 Connect   root@172.100.10.10 on  using SSL/TLS
2021-05-12T11:54:09.127452Z        76 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:09.127590Z        76 Query     SHOW WARNINGS
2021-05-12T11:54:09.127680Z        76 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:09.127790Z        76 Query     SHOW WARNINGS
......
2021-05-12T11:54:10.018813Z        90 Connect   root@172.100.10.10 on  using SSL/TLS
2021-05-12T11:54:10.018944Z        90 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:10.019047Z        90 Query     SHOW WARNINGS
2021-05-12T11:54:10.019150Z        90 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:10.019226Z        90 Query     SHOW WARNINGS
2021-05-12T11:54:10.025833Z        91 Connect   root@172.100.10.10 on  using SSL/TLS
2021-05-12T11:54:10.025934Z        91 Query     SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2021-05-12T11:54:10.026048Z        91 Query     SHOW WARNINGS
2021-05-12T11:54:10.026141Z        91 Query     START TRANSACTION WITH CONSISTENT SNAPSHOT
2021-05-12T11:54:10.026219Z        91 Query     SHOW WARNINGS
2021-05-12T11:54:10.026293Z        75 Query     UNLOCK TABLES  //结束锁表
2021-05-12T11:54:10.026406Z        75 Query     SHOW WARNINGS

可以看到并行导出之前,有一个线程加上了全局读锁,然后等所有的并发线程打开事务之后才解锁了表,因此并行导出的时候也是数据一致的。

优缺点

  • 优点:
    • 并行备份数据库和数据库中的对象,比 mysqldump 更高效。
    • 更好的控制数据库和数据库对象(表,存储过程,用户帐户)的备份。
    • 备份进度可视化。
  • 缺点:  
    • 只能并行到表级别,如果有一个表数据量特别大那么会存在非常严重的短板效应。
    • 导出的数据保存在一个文件中,导入仍旧是单线程,效率较低。
    • 无法获取当前备份对应的binlog位置。

总结一下

尽管 mysqlpump 还有非常多的不足,但是相比较于原始的 mysqldump 已经有了非常大的进步,从这个工具的发布也可以看出来 Oracle 终于开始重视 MySQL 的生态工具了,期待官方提供更多的更优秀的生态工具。

以上就是MySQL官方导出工具mysqlpump的使用的详细内容,更多关于mysqlpump的使用的资料请关注三水点靠木其它相关文章!

MySQL 相关文章推荐
mysql死锁和分库分表问题详解
Apr 16 MySQL
MySQL 使用事件(Events)完成计划任务
May 24 MySQL
修改MySQL的默认密码的四种小方法
May 26 MySQL
详解MySQL中的主键与事务
May 27 MySQL
mysql外连接与内连接查询的不同之处
Jun 03 MySQL
MySQL8.0.18配置多主一从
Jun 21 MySQL
MySQL开启事务的方式
Jun 26 MySQL
MySQL系列之九 mysql查询缓存及索引
Jul 02 MySQL
MySQL外键约束(FOREIGN KEY)案例讲解
Aug 23 MySQL
MySQL修改默认引擎和字符集详情
Sep 25 MySQL
MySQ InnoDB和MyISAM存储引擎介绍
Apr 26 MySQL
MySQL聚簇索引和非聚簇索引的区别详情
Jun 14 MySQL
新手必备之MySQL msi版本下载安装图文详细教程
MySQL数据库压缩版本安装与配置详细教程
MySQL 8.0 之不可见列的基本操作
May 20 #MySQL
Mysql Online DDL的使用详解
May 20 #MySQL
MySQL 存储过程的优缺点分析
May 20 #MySQL
IDEA 链接Mysql数据库并执行查询操作的完整代码
MySQL 覆盖索引的优点
May 19 #MySQL
You might like
《斗罗大陆》六翼天使武魂最强,为什么老千家不是上三宗?
2020/03/02 国漫
PHP文件读写操作之文件写入代码
2011/01/13 PHP
PHP中mysqli_affected_rows作用行数返回值分析
2014/12/26 PHP
php计算整个目录大小的方法
2015/06/01 PHP
用javascript实现的仿Flash广告图片轮换效果
2007/04/24 Javascript
一个报数游戏js版(约瑟夫环问题)
2010/08/05 Javascript
javascript new fun的执行过程
2010/08/05 Javascript
onclick与listeners的执行先后问题详细解剖
2013/01/07 Javascript
JS之Date对象和获取系统当前时间详解
2014/01/13 Javascript
node.js中的fs.writeFile方法使用说明
2014/12/14 Javascript
js数组常见操作及数组与字符串相互转化实例详解
2015/11/10 Javascript
6种javascript显示当前系统时间代码
2015/12/01 Javascript
JavaScript中的Array 对象(数组对象)
2016/06/02 Javascript
jQuery实现倒计时(倒计时年月日可自己输入)
2016/12/02 Javascript
JavaScript实现经典排序算法之插入排序
2016/12/28 Javascript
docker中编译nodejs并使用nginx启动
2017/06/23 NodeJs
ReactNative踩坑之配置调试端口的解决方法
2017/07/28 Javascript
jQuery轮播图实例详解
2018/08/15 jQuery
写gulp遇到的ES6问题详解
2018/12/03 Javascript
[03:43]TI9战队采访——PSG.LGD
2019/08/22 DOTA
Python MySQLdb模块连接操作mysql数据库实例
2015/04/08 Python
Python编程实现线性回归和批量梯度下降法代码实例
2018/01/04 Python
基于Python socket的端口扫描程序实例代码
2018/02/09 Python
Python经纬度坐标转换为距离及角度的实现
2020/11/01 Python
英国玛莎百货新西兰:Marks & Spencer New Zealand
2019/07/21 全球购物
STP的判定过程
2012/10/01 面试题
如何手工释放资源
2013/12/15 面试题
实体的生命周期
2013/08/31 面试题
日语专业毕业生自荐信
2013/11/11 职场文书
公司人力资源的自我评价
2014/01/02 职场文书
工程造价专业求职信
2014/07/17 职场文书
XX部保密工作制度范本
2019/08/27 职场文书
五年级作文之学校的四季
2019/12/05 职场文书
解决Goland 同一个package中函数互相调用的问题
2021/05/06 Golang
Python Flask请求扩展与中间件相关知识总结
2021/06/11 Python
SpringBoot+Vue+JWT的前后端分离登录认证详细步骤
2021/09/25 Java/Android