我們將比較mysqldump和MySQL Shell實用工具的備份和恢復(fù)速度。

以下工具用于速度比較：

• mysqldump

• util.dumpInstance

• util.loadDump

硬件配置

兩臺具有相同配置的獨立服務(wù)器。

服務(wù)器1

   * IP：192.168.33.14

   * CPU：2核心

   * RAM：4 GB

   *磁盤：200 GB SSD

服務(wù)器2

   * IP：192.168.33.15

   * CPU：2核心

   * RAM：4 GB

   *磁盤：200 GB SSD

工作量準(zhǔn)備

在服務(wù)器1（192.168.33.14）上，我們已加載約10 GB數(shù)據(jù)。

現(xiàn)在，我們想將數(shù)據(jù)從服務(wù)器1（192.168.33.14）還原到服務(wù)器2（192.168.33.15）。

MySQL設(shè)置

MySQL版本：8.0.22

InnoDB緩沖池大?。? GB

InnoDB日志文件大?。?6 MB

二進制記錄：開

我們使用sysbench加載了5000萬條記錄。

測試案例一

在這種情況下，我們將使用mysqldump命令進行邏輯備份。

例 

[root@centos14 vagrant]# time /usr/bin/mysqldump --defaults-file=/etc/my.cnf  --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --triggers --routines --events  --set-gtid-purged=OFF  --all-databases  |gzip -6 -c > /home/vagrant/test/mysqldump_schemaanddata.sql.gz

start_time = 2020-11-09 17:40:02

end_time = 2020-11-09 37:19:08

轉(zhuǎn)儲所有大約10GB的數(shù)據(jù)庫花了將近20分鐘19秒。

測試案例二

現(xiàn)在讓我們嘗試使用MySQL Shell實用程序。我們將使用dumpInstance進行完整備份。

例 

整個數(shù)據(jù)庫的轉(zhuǎn)儲（與mysqldump所使用的數(shù)據(jù)相同）總共花費了1分27秒，并且它還顯示了其進度，這對于了解已完成多少備份非常有幫助。它給出了執(zhí)行備份所花費的時間。

并行性取決于服務(wù)器中的內(nèi)核數(shù)量。在我的情況下，大約增加價值不會有幫助。（我的機器有2個核心）。

恢復(fù)速度測試 

在還原部分，我們將在另一臺獨立服務(wù)器上還原mysqldump備份。備份文件已使用rsync移動到目標(biāo)服務(wù)器。

測試用例1 

例 

[root@centos15 vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -p

恢復(fù)10GB數(shù)據(jù)大約需要16分26秒。

測試案例2 

在這種情況下，我們使用mysql shell實用程序?qū)浞菸募虞d到另一個獨立主機上。我們已經(jīng)將備份文件移到了目標(biāo)服務(wù)器。讓我們開始還原過程。

例 

恢復(fù)10GB數(shù)據(jù)花費了大約40分鐘6秒。

現(xiàn)在，讓我們嘗試禁用重做日志并使用mysql shell實用程序開始數(shù)據(jù)導(dǎo)入。

禁用重做日志后，平均吞吐量提高到2倍。

注意：請勿在生產(chǎn)系統(tǒng)上禁用重做日志記錄。它允許在禁用重做日志記錄的同時關(guān)閉服務(wù)器并重新啟動，但是在禁用重做日志記錄的情況下服務(wù)器意外停機會導(dǎo)致數(shù)據(jù)丟失和實例損壞。

物理備份 

您可能已經(jīng)注意到，即使是多線程的邏輯備份方法，即使對于我們對其進行測試的小型數(shù)據(jù)集，也非常耗時。這就是為什么ClusterControl提供基于文件復(fù)制的物理備份方法的原因之一-在這種情況下，我們不受處理邏輯備份的SQL層的限制，而是受硬件的限制-磁盤讀取文件的速度和網(wǎng)絡(luò)在數(shù)據(jù)庫節(jié)點和備份服務(wù)器之間傳輸數(shù)據(jù)的速度。

ClusterControl提供了不同的方法來實施物理備份，哪種方法可用取決于群集類型，有時甚至取決于供應(yīng)商。讓我們看一下由ClusterControl執(zhí)行的Xtrabackup，它將在我們的測試環(huán)境中創(chuàng)建數(shù)據(jù)的完整備份。

這次我們將創(chuàng)建臨時備份，但是ClusterControl允許您也創(chuàng)建完整的備份計劃。

在這里，我們選擇備份方法（xtrabackup）以及將從中進行備份的主機。我們還可以將其本地存儲在節(jié)點上，也可以將其流式傳輸?shù)?/span>ClusterControl實例。此外，您可以將備份上傳到云（支持AWS，Google Cloud和Azure）。

備份大約需要10分鐘才能完成。這里是來自cmon_backup.metadata文件的日志。

現(xiàn)在，讓我們嘗試使用ClusterControl進行相同的還原。ClusterControl>備份>恢復(fù)備份 。

在這里，我們選擇還原備份選項，它還將支持基于時間和日志的還原。

在這里，我們選擇備份文件的源路徑，然后選擇目標(biāo)服務(wù)器。您還必須確?？梢?/span>使用SSH從ClusterControl節(jié)點訪問此主機。

我們不希望ClusterControl設(shè)置軟件，因此我們禁用了該選項?；謴?fù)后，它將保持服務(wù)器運行。

恢復(fù)10GB數(shù)據(jù)大約需要4分18秒。Xtrabackup不會在備份過程中鎖定數(shù)據(jù)庫。對于大型數(shù)據(jù)庫（100+ GB），與mysqldump / shell實用程序相比，它提供了更好的還原時間。正如我的一位同事在其博客中所解釋的那樣，lusterControl還支持部分備份和還原：部分備份和還原。

結(jié)論

每種方法都有其優(yōu)點和缺點。如我們所見，沒有一種方法可以最好地滿足您的所有需求。我們需要根據(jù)生產(chǎn)環(huán)境和目標(biāo)恢復(fù)時間來選擇工具。