如何從服務(wù)器上做備份？

發(fā)布：2018-06-22 15:56:37 瀏覽：3666

對備份，只是希望在進入正式話題之前，允許給一些小提示。

●在備份上不要拖延，做備份其實并不難。

●做事不要追求完美，而要追求可恢復(fù)。

●至少對于可接受的數(shù)據(jù)損失、可接受的宕機時間、數(shù)據(jù)持續(xù)策略以及安全需求要形成文檔。

●對恢復(fù)過程要進行練習并形成文檔，恢復(fù)比備份要重要得多!

●對于備份作業(yè)成功與否，要進行外部驗證，不要依賴于作業(yè)自身對你的提示。

下面，讓我們將繁文縟節(jié)的形式拋在一邊，看看怎么用復(fù)制從服務(wù)器做備份。

首先，最顯然的事情，是將從服務(wù)器自身作為備份。不幸的是，這并非一個真正的備份。在發(fā)生問題時，如丟失了服務(wù)器或其一部分、惡意攻擊造成的數(shù)據(jù)破壞、偶然的DROPTABLE，真正的備份能夠挽回損失，而復(fù)制從服務(wù)器對于上述后兩個問題所造成的數(shù)據(jù)損失，卻是無能為力的，因為它只是好心地將數(shù)據(jù)變化復(fù)制了過來，從而將數(shù)據(jù)的破壞或損失也一并復(fù)制了過來。

所以，怎么做真正的備份呢?假如只有一臺復(fù)制從服務(wù)器，而且這臺服務(wù)器也有多余的空間做cron作業(yè)等，則在不用數(shù)據(jù)庫服務(wù)器的時候，將其停掉，然后備份其數(shù)據(jù)。對于MYSQL:在MYSQL進程運行的時候，不要復(fù)制IINNODB的文件，這樣是無法復(fù)制的。如果能夠停掉MYSQL，然后將其數(shù)據(jù)移走，則對于大多數(shù)情況，都是最安全的。

如果不想停止服務(wù)器，還有一個選擇，就是Ktrabackup，一個免費和開源的非阻塞備份程序，用于備份INNODB和KTRADBE的表。假如有MYISAM表，則在復(fù)制時會進行鎖定。Xtrabackup基于與INNODBI的熱備工具同樣的原理，但XTRADB開源，且具有一些額外的特點。

我過去建議人們使用文件系統(tǒng)快照，特別是LVM快照。這些快照也可以創(chuàng)建備份，而又不會打斷數(shù)據(jù)庫的操作。但經(jīng)過一些基準測試，我和我的同事都不再推薦這種方法了。LVM的問題是影響性能，而且比我們過去認為的影響要大得多。其他有快照能力的文件系統(tǒng)，如ZFS，相對比較新，我也不是這方面的專家，所以也就沒什么可說的。我的有些客戶使用Solaris和ZFS，盡管很難分離各個變量，或者直接比較性能，但我并不認為性能有明顯的好轉(zhuǎn)。ZFS寫時復(fù)制(copy-on-write)的行為，使得關(guān)于數(shù)據(jù)如何物理組織的考慮變得很復(fù)雜了，關(guān)于這方面，我還沒有足夠的時間來熟悉，所以也就無法做出合理的推薦。所以，在我看來，將ZFS用做數(shù)據(jù)庫的文件系統(tǒng)，還仍然沒有取得一致意見。所以，在開源領(lǐng)域，我還沒有見到基于快照的備份的殺手級解決方案。

關(guān)于MYSQLI的，而MYSQL沒有這種能力，所以，MYSQL的備份就有點復(fù)雜了。很多數(shù)據(jù)庫都有內(nèi)置的熱備能力，如果你的數(shù)據(jù)庫有，就使用它。前面的討論大部分都是對于MYSQL，可能其他數(shù)據(jù)庫也一樣，可以用復(fù)制從服務(wù)器來做這樣的事:將復(fù)制延遲一段時間，如一個小時。這可以使用Maatkitt的mk-slave-delay工具來實現(xiàn)。將延遲的服務(wù)器用

做“備份”，有下面兩個有趣的點:

●不斷地從主服務(wù)器中獲取更新，但并不應(yīng)用這些更新，這意味著，比起昨天晚上做的備份(在發(fā)生崩潰的時候，備份的數(shù)據(jù)可能已經(jīng)過去24小時了)，丟失數(shù)據(jù)的機會要低得多。在延遲時間到達時，服務(wù)器將應(yīng)用從主服務(wù)器中獲取的更新。

●假如發(fā)生問題，這種延遲會給你一段緩沖時間。偶然的DROPTABLE，在你的從服務(wù)器上會延遲一個小時才會發(fā)生，所以，在又對主服務(wù)器上的表進行恢復(fù)等類似操作時，可以跳過從服務(wù)器上DROP，并將從服務(wù)器切換為主服務(wù)器。這段額外的延遲時間，給了恢復(fù)操作相當?shù)倪x擇空間。

將延遲從網(wǎng)站建設(shè)服務(wù)器用做備份的補充，而不是替代。你仍然需要做實際的備份!