Mysqldump是MySQL最流行的邏輯備份工具。它包含在MySQL發(fā)行版中，因此可以在所有MySQL實例上使用。 

但是，邏輯備份不是備份MySQL數(shù)據(jù)庫的最快也是最節(jié)省空間的方法，但是與物理備份相比，它們具有巨大的優(yōu)勢。 

物理備份通常是全部備份或不備份。盡管可以使用Xtrabackup創(chuàng)建部分備份（我們在以前的博客文章之一中對此進行了描述），但是還原這種備份既棘手又費時。 

基本上，如果要還原單個表，則必須停止整個復制鏈，并立即在所有節(jié)點上執(zhí)行恢復。這是一個主要問題-如今，您很少負擔停止所有數(shù)據(jù)庫的費用。 

另一個問題是表級別是Xtrabackup可以實現(xiàn)的最低粒度級別：您可以還原單個表，但不能還原其中的一部分。但是，可以通過運行SQL語句的方式來恢復邏輯備份，因此可以在正在運行的群集上輕松地執(zhí)行邏輯備份，并且您可以（雖然我們不容易稱呼它，但仍然可以）選擇要運行的SQL語句，因此您可以對表進行部分還原。 

讓我們看一下如何在現(xiàn)實世界中做到這一點。

使用mysqldump還原單個MySQL表

剛開始時，請記住，部分備份不能提供一致的數(shù)據(jù)視圖。當您備份單獨的表時，即使您要從備份中還原所有數(shù)據(jù)，也無法及時將這種備份還原到已知位置（例如，配置復制從屬）。有了這些，讓我們繼續(xù)吧。

我們有一個主人和一個奴隸：

數(shù)據(jù)集包含一個模式和幾個表：

現(xiàn)在，我們必須備份。有幾種方法可以解決此問題。我們可以對整個數(shù)據(jù)集進行一致的備份，但這將生成一個包含所有數(shù)據(jù)的大型單個文件。要恢復單個表，我們將不得不從該文件中提取表的數(shù)據(jù)。當然可以，但是這很耗時，可以手動編寫腳本，但是如果沒有適當?shù)哪_本，那么當數(shù)據(jù)庫宕機并且承受沉重壓力時編寫臨時代碼是非常困難的。不一定是最安全的主意。

取而代之的是，我們可以通過將每個表存儲在單獨文件中的方式來準備備份：

請注意，我們設置--set-gtid-purged = OFF。如果以后要將此數(shù)據(jù)加載到數(shù)據(jù)庫中，則需要它。否則，MySQL將嘗試設置@@ GLOBAL.GTID_PURGED，這很可能會失敗。MySQL最好將SET @@ SESSION.SQL_LOG_BIN = 0設置為; 這絕對不是我們想要的。如果我們要對整個數(shù)據(jù)集進行一致的備份，并且我們想使用它來設置新節(jié)點，則需要這些設置。在我們的案例中，我們知道這不是一致的備份，因此我們無法從中重建任何內(nèi)容。我們只需要生成一個轉(zhuǎn)儲文件，然后將其加載到主服務器上，然后將其復制到從服務器上即可。

該命令生成了一個不錯的sql文件列表，可以將其上傳到生產(chǎn)集群：

當您想要還原數(shù)據(jù)時，您所需要做的就是將SQL文件加載到主節(jié)點中：

數(shù)據(jù)將被加載到數(shù)據(jù)庫中并復制到所有從站。

如何使用ClusterControl還原單個MySQL表？

當前，ClusterControl不能提供一種簡單的方法來恢復單個表，但是仍然可以通過一些手動操作來恢復它。您可以使用兩個選項。首先，適用于少量表，基本上可以創(chuàng)建計劃，在該計劃中對一個單獨的表進行部分備份：

在這里，我們正在備份sbtest.sbtest1表。我們可以輕松地為sbtest2表安排另一個備份：

或者，我們可以執(zhí)行備份并將數(shù)據(jù)從單個模式放入單獨的文件中：

現(xiàn)在，您可以在文件中手動找到丟失的數(shù)據(jù)，將此備份還原到單獨的服務器，或者讓ClusterControl進行：

您可以保持服務器正常運行，并且可以使用mysqldump或SELECT…INTO OUTFILE提取要還原的數(shù)據(jù)。這樣提取的數(shù)據(jù)將準備好應用于生產(chǎn)集群。