MySQL官方導出工具mysqlpump的使用
更新時間：2021年05月21日 10:28:22 作者：王文安@DBA
備份恢復是 DBA 繞不開的核心話題，市面上也有很多開源的備份恢復方案，不過官方的 mysqldump 一直是處于鄙視鏈底端的那個。終于，官方在 MySQL5.7 之后新添加了一個備份工具：mysqlpump，本文將簡單的介紹該工具的使用
簡介
mysqlpump 是 mysqldump 的一個衍生，本身也參考了 mydumper 的思路，支持了并行導出數據，因此導出數據的效率比 mysqldump 會高很多。
使用介紹
mysqlpump 的絕大多數參數與 mysqldump 是一樣的，整體的使用方法和 mysqldump 沒有太多的差異。這里列出一部分 mysqlpump 中比較重要且常用的參數。
|
參數 |
說明 |
|---|---|
|
--default-parallelism=# |
設置并行導出的并發(fā)度，與 single-transaction 沖突 |
|
--single-transaction |
創(chuàng)建一個單獨的事務來導出所有的表 |
|
--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的優(yōu)先級會高于default-parallelism。
去掉single-transaction再進行測試的時候，會發(fā)現(xiàn)一個比較有意思的現(xiàn)象，觀察 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
可以看到并行導出之前，有一個線程加上了全局讀鎖，然后等所有的并發(fā)線程打開事務之后才解鎖了表，因此并行導出的時候也是數據一致的。
優(yōu)缺點
- 優(yōu)點：
- 并行備份數據庫和數據庫中的對象，比 mysqldump 更高效。
- 更好的控制數據庫和數據庫對象（表，存儲過程，用戶帳戶）的備份。
- 備份進度可視化。
- 缺點：
- 只能并行到表級別，如果有一個表數據量特別大那么會存在非常嚴重的短板效應。
- 導出的數據保存在一個文件中，導入仍舊是單線程，效率較低。
- 無法獲取當前備份對應的binlog位置。
總結一下
盡管 mysqlpump 還有非常多的不足，但是相比較于原始的 mysqldump 已經有了非常大的進步，從這個工具的發(fā)布也可以看出來 Oracle 終于開始重視 MySQL 的生態(tài)工具了，期待官方提供更多的更優(yōu)秀的生態(tài)工具。
以上就是MySQL官方導出工具mysqlpump的使用的詳細內容，更多關于mysqlpump的使用的資料請關注腳本之家其它相關文章！
您可能感興趣的文章:
- mysqldump你可能不知道的參數
- MySQL5.7 mysqldump備份與恢復的實現(xiàn)
- linux使用mysqldump+expect+crontab實現(xiàn)mysql周期冷備份思路詳解
- MySql使用mysqldump 導入與導出方法總結
- MySQL之mysqldump的使用詳解
- 如何用mysqldump進行全量和時間點備份
- docker 使用mysqldump命令備份導出項目中的mysql數據
- MySQL數據遷移使用MySQLdump命令
- PHP定時備份MySQL與mysqldump語法參數詳解
- mysql備份腳本 mysqldump使用方法詳解
- 詳解 linux mysqldump 導出數據庫、數據、表結構
- 詳談mysqldump數據導出的問題
相關文章
這篇文章主要為大家詳細介紹了MySql安裝與使用圖文教程，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-03-03
針對十億級MySQL大表的查詢優(yōu)化,本文主要介紹了10種經過驗證的核心優(yōu)化策略及對應SQL實現(xiàn)方案,具有一定的參考價值,感興趣的可以了解一下2025-03-03
Mysql8.0密碼問題mysql_native_password和caching_sha2_password詳解
這篇文章主要介紹了Mysql8.0密碼問題mysql_native_password和caching_sha2_password,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-08-08
mysql5.7創(chuàng)建用戶授權刪除用戶撤銷授權
這篇文章主要介紹了mysql5.7創(chuàng)建用戶授權刪除用戶撤銷授權的方法,非常不錯，具有參考借鑒價值，需要的朋友可以參考下2017-02-02
MySql Error 1698(28000)問題的解決方法
這篇文章主要介紹了MySql Error 1698(28000)問題的解決方法,需要的朋友可以參考下2017-06-06
詳解Spring Aop實現(xiàn)日志收集和重復屬性賦值
AOP（面向切面編程）是一種編程思想,它允許開發(fā)者將公共邏輯（如日志記錄、權限校驗等）抽離出來,使得可以更專注于業(yè)務邏輯的開發(fā),SpringAOP通過定義切面、切入點、通知等概念,本文介紹Spring Aop實現(xiàn)日志收集和重復屬性賦值的相關操作,感興趣的朋友一起看看吧2023-04-04
MySQL配置了雙主,是如何避免出現(xiàn)數據回環(huán)沖突的
這篇文章主要介紹了MySQL配置了雙主，是如何避免出現(xiàn)數據回環(huán)沖突的,幫助大家更好的理解和使用MySQL數據庫，感興趣的朋友可以了解下2021-01-01
MySQL數據庫的varchar類型在5.0.3以下的版本中的最大長度限制為255，其數據范圍可以是0~2552012-06-06
這篇文章主要介紹了幾種在Linux中找到MySQL的安裝目錄方法,包括使用which命令、whereis命令、檢查服務狀態(tài)、直接查詢MySQL以及查閱配置文件,文中通過代碼介紹的非常詳細,需要的朋友可以參考下2025-04-04
MySQL實現(xiàn)字符串的拼接,截取,替換,查找位置的操作
這篇文章主要介紹了MySQL實現(xiàn)字符串的拼接,截取,替換,查找位置的操作，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2021-02-02