目錄簡介使用介紹實際體驗優(yōu)缺點總結(jié)一下簡介

mysqlpump 是 mysqldump 的一個衍生，本身也參考了 mydumper 的思路，支持了并行導(dǎo)出數(shù)據(jù)，因此導(dǎo)出數(shù)據(jù)的效率比 mysqldump 會高很多。

使用介紹

mysqlpump 的絕大多數(shù)參數(shù)與 mysqldump 是一樣的，整體的使用方法和 mysqldump 沒有太多的差異。這里列出一部分 mysqlpump 中比較重要且常用的參數(shù)。

參數(shù)

說明

--default-parallelism=#

設(shè)置并行導(dǎo)出的并發(fā)度，與 single-transaction 沖突

--single-transaction

創(chuàng)建一個單獨的事務(wù)來導(dǎo)出所有的表

--exclude-databases=name

導(dǎo)出時排除掉某些庫，多個庫以逗號分隔

--exclude-tables=name

導(dǎo)出時排除掉某些表，多個表以逗號分隔

--include-databases=name

導(dǎo)出時包含某些庫，多個庫以逗號分隔

--include-tables=name

導(dǎo)出時包含某些表，多個表以逗號分隔

實際體驗

這里對 mysqlpump 做一次簡單的試用，目標實例選擇 MySQL 5.7，參數(shù)中同時采用了single-transaction和default-parallelism，試試看這個沖突的效果。

mysqlpump 側(cè)的輸出參考如下信息：

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

可以看到當這兩個參數(shù)同時啟用的時候，mysqlpump 實際上還是在一個一個表的導(dǎo)出。single-transaction的優(yōu)先級會高于default-parallelism。

去掉single-transaction再進行測試的時候，會發(fā)現(xiàn)一個比較有意思的現(xiàn)象，觀察 MySQL 的 processlist，會有如下結(jié)果：

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 的“并行導(dǎo)出”實際上只是基于表級別的并行導(dǎo)出，當存在單個大表的時候，導(dǎo)出的時間會被嚴重的影響，存在短板效應(yīng)。

額外的疑問：如果default-parallelism和single-transaction有沖突的話，那么并行導(dǎo)出的時候是不是無法確認數(shù)據(jù)一致性？

實踐出真實，打開 general_log 看一下導(dǎo)出時的操作：

2021-05-12T11:54:09.033215Z75 Connect root@172.100.10.10 on using SSL/TLS2021-05-12T11:54:09.075347Z75 Query FLUSH TABLES WITH READ LOCK //開始鎖表2021-05-12T11:54:09.103132Z75 Query SHOW WARNINGS2021-05-12T11:54:09.106382Z75 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ2021-05-12T11:54:09.106553Z75 Query SHOW WARNINGS2021-05-12T11:54:09.106640Z75 Query START TRANSACTION WITH CONSISTENT SNAPSHOT2021-05-12T11:54:09.108115Z75 Query SHOW WARNINGS2021-05-12T11:54:09.127277Z76 Connect root@172.100.10.10 on using SSL/TLS2021-05-12T11:54:09.127452Z76 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ2021-05-12T11:54:09.127590Z76 Query SHOW WARNINGS2021-05-12T11:54:09.127680Z76 Query START TRANSACTION WITH CONSISTENT SNAPSHOT2021-05-12T11:54:09.127790Z76 Query SHOW WARNINGS......2021-05-12T11:54:10.018813Z90 Connect root@172.100.10.10 on using SSL/TLS2021-05-12T11:54:10.018944Z90 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ2021-05-12T11:54:10.019047Z90 Query SHOW WARNINGS2021-05-12T11:54:10.019150Z90 Query START TRANSACTION WITH CONSISTENT SNAPSHOT2021-05-12T11:54:10.019226Z90 Query SHOW WARNINGS2021-05-12T11:54:10.025833Z91 Connect root@172.100.10.10 on using SSL/TLS2021-05-12T11:54:10.025934Z91 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ2021-05-12T11:54:10.026048Z91 Query SHOW WARNINGS2021-05-12T11:54:10.026141Z91 Query START TRANSACTION WITH CONSISTENT SNAPSHOT2021-05-12T11:54:10.026219Z91 Query SHOW WARNINGS2021-05-12T11:54:10.026293Z75 Query UNLOCK TABLES //結(jié)束鎖表2021-05-12T11:54:10.026406Z75 Query SHOW WARNINGS

可以看到并行導(dǎo)出之前，有一個線程加上了全局讀鎖，然后等所有的并發(fā)線程打開事務(wù)之后才解鎖了表，因此并行導(dǎo)出的時候也是數(shù)據(jù)一致的。

優(yōu)缺點 優(yōu)點： 并行備份數(shù)據(jù)庫和數(shù)據(jù)庫中的對象，比 mysqldump 更高效。更好的控制數(shù)據(jù)庫和數(shù)據(jù)庫對象（表，存儲過程，用戶帳戶）的備份。備份進度可視化。 缺點： 只能并行到表級別，如果有一個表數(shù)據(jù)量特別大那么會存在非常嚴重的短板效應(yīng)。導(dǎo)出的數(shù)據(jù)保存在一個文件中，導(dǎo)入仍舊是單線程，效率較低。無法獲取當前備份對應(yīng)的binlog位置。總結(jié)一下

盡管 mysqlpump 還有非常多的不足，但是相比較于原始的 mysqldump 已經(jīng)有了非常大的進步，從這個工具的發(fā)布也可以看出來 Oracle 終于開始重視 MySQL 的生態(tài)工具了，期待官方提供更多的更優(yōu)秀的生態(tài)工具。

以上就是MySQL官方導(dǎo)出工具mysqlpump的使用的詳細內(nèi)容，更多關(guān)于mysqlpump的使用的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！