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

以下工具用于速度比較：

• mysqldump

• util.dumpInstance

• util.loadDump

硬件配置

兩臺(tái)具有相同配置的獨(dú)立服務(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日志文件大小：16 MB

二進(jìn)制記錄：開

我們使用sysbench加載了5000萬(wàn)條記錄。

測(cè)試案例一

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

例 

[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)儲(chǔ)所有大約10GB的數(shù)據(jù)庫(kù)花了將近20分鐘19秒。

測(cè)試案例二

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

例 

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

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

恢復(fù)速度測(cè)試 

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

測(cè)試用例1 

例 

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

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

測(cè)試案例2 

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

例 

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

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

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

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

物理備份 

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

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

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

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

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

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

在這里，我們選擇還原備份選項(xiàng)，它還將支持基于時(shí)間和日志的還原。

在這里，我們選擇備份文件的源路徑，然后選擇目標(biāo)服務(wù)器。您還必須確保可以使用SSH從ClusterControl節(jié)點(diǎn)訪問此主機(jī)。

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

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

結(jié)論

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