【評論有獎】數據高可用備份教程開放，無效「全額退款」

08-12

7 人贊了文章

看完本帖，你將收穫

華為雲技術專家教你的數據備份永不出錯的訣竅

和萌寵加濕器一個

生產環境的資料庫多數是帶備份的，至少是一主一備，目的是當主機出現宕機但是又不能很快恢復時，把業務切換到備機上，快速恢復業務，但是備機也可能會故障，有時候還需要基於當前的數據做一份新的資料庫出來，此時怎麼做？是不是還得一個冷備份呢？所以基本的資料庫架構很多是這樣的：

資料庫基本架構

最初我們做RDS for MySQL 備份也是基於這樣的模型，但不同的是，我們引入了對象存儲系統（Object Storage）。因為實例較多，發生切換時不能靠人工處理，因此引入了高可用系統（High Available）。針對備份，我們也抽象出一個獨立系統，用來處理複雜的備份和還原過程，稱之為備份恢復系統（Backup and Restore）。最終的框架圖如下：

高可用備份框架圖

優化：

觸發備份時，可能會導致主機資源被佔用，例如壓縮時佔用 CPU 資源，上傳會佔用IO，所以業界RDS for MySQL都會在備機上做備份，但是僅僅是換個主機這麼簡單嗎？下面重點說說我們在此過程中踩過的一個坑吧！

敲黑板劃重點：

基於備機備份第1個帶來的問題我們要正視，那就是可能的延遲，整體上延遲時間為：

OBS上的數據時間 晚於 備機的數據時間 晚於 主機的數據時間

即：OBS上的數據可能晚於備機的數據，而後者又晚於主機的數據。

這個延遲會帶來其它問題，我們在做高可用和可靠性混合測試時碰到過。

假設A的uuid為A，B的uuid為B，具體操作步驟和數據如下：

操作主機A主機BOBS

看下我們測試的結果：

圖1 新備機

圖2 新主機

大家注意，如果這部分數據沒有同步過來其實是一個非常危險的動作。因為此時主備複製關係都是正常的，所以很容易被忽略。而且由於這樣的延遲關係，該場景下的問題的發生是一個大概率事件。

很顯現，MySQL並沒有按照大家想像中那樣去做。很多 DBA 都做過這樣的實驗，把已經從主機同步過來的數據在備機刪除掉，然後設置已經執行的 GTID 為之前的值，數據會重新從主機同步過來，而且只認 GTID 不認內容，可是為什麼現在就不行了呢？

在此過程中，我們進行了各種檢查。先是驗證是否備份出現問題，然後又驗證是否還原步驟出現問題，然而都不是…… 總不能是資料庫 A 通過識別 GTID 發現，有部分數據是以自己的 uuid 開頭，所以才沒有同步吧？

所以我們嘗試修改了A主機的server-uuid為C，但並沒有任何結果。這樣的結果，一度讓我的思路陷入僵局，感覺大腦中的主備複製知識要被刷新了。打開解析後的binlog，看到 binlog 中使用的是 server ID，我想mysql是不是通過server ID來識別呢？抱著病重亂投醫的心態，我嘗試修改了 server ID，結果卻意外地成功了！於是我們又順著這條線索，查看 MySQL 官方文檔，發現一個不常用參數。

--replicate-same-server-id

Command-Line Format

--replicate-same-server-id

Permitted Values

Type

boolean

Default

FALSE

To be used on slave servers. Usually you should use the default setting of 0, to prevent infinite loops caused by circular replication. If set to 1, the slave does not skip events having its own server ID. Normally, this is useful only in rare configurations. The option cannot be set to 1 when is enabled, which is the default.

By default, the slave I/O thread does not write binary log events to the relay log if they have the slaves server ID (this optimization helps save disk usage). If you want to use , be sure to start the slave with this option before you make the slave read its own events that you want the slave SQL thread to execute.

--log-slave-updates enables replication servers to be chained. For example, you might want to set up replication servers using this arrangement:

A -> B -> C

Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. With binary logging and the --log-slave-updates option enabled, which are the default settings, updates received from A are logged by B to its binary log, and can therefore be passed on to C.

大意是說：

為防止循環複製引起的無限循環，備機默認設置通常為0。一旦設置為1，備機會忽略那些同自己具有相同server ID的事件，所以會出現上面我們遇到的問題。

測試了一遍，是它！

又測試一遍，是它！

再測試一遍，還真是它！

本以為找到了救命的靈丹妙藥，但接下來的問題還是讓我們面面相覷。

官方文檔寫明replicate-same-server-id 與 log-slave-updates 互斥關係，而log-slave-updates則是我們在備機做備份必須開啟的參數，所以該參數我們不能設置為on，這就相當尷尬了……

目前這個問題只能規避，例如在每次恢復的時候，重新設置server ID 為一個不重複的值。而且 MySQL不推薦使用重複的 ID 值，也是為了防止出現無限循環複製。

此外，補充一個注意事項，就是在備機做運維動作時，對於修改數據、flush等這類會寫bin-log 的操作時，一定要先執行 set sql_log_bin=0，否則你的每一筆操作，都會造成備機少同步一條數據。

文章到此結束，該問題的發現、重現、定位及解決，在追求數據的最大可靠性上，我們從不懈怠。