不同場景下 MySQL 的遷移方案

2021-07-05 07:55:53 字數 2779 閱讀 5491

五 注意事項

六 技巧

七 總結

mysql 遷移是 dba 日常維護中的乙個工作。遷移,究其本義,無非是把實際存在的物體挪走,保證該物體的完整性以及延續性。就像柔軟的沙灘上,兩個天真無邪的小孩,把一堆沙子挪向其他地方,鑄就內心神往的城堡。

生產環境中,有以下情況需要做遷移工作,如下:

一句話,遷移工作是不得已而為之。實施遷移工作,目的是讓業務平穩持續地執行。

mysql 遷移無非是圍繞著資料做工作,再繼續延伸,無非就是在保證業務平穩持續地執行的前提下做備份恢復。那問題就在怎麼快速安全地進行備份恢復。

另一方面,恢復。針對小容量(10gb 以下)資料庫的備份檔案,我們可以直接匯入。針對大容量資料庫(數百gb 或者 tb 級別)的恢復,拿到備份檔案到本機以後,恢復不算困難。具體的恢復方法可以參考第四節。

我們搞明白為什麼要做遷移,以及遷移怎麼做以後,接下來看看生產環境是怎樣操作的。不同的應用場景,有不同的解決方案。

閱讀具體的實戰之前,假設和讀者有如下約定:

為了保護隱私,本文中的伺服器 ip 等資訊經過處理;

如果伺服器在同一機房,用伺服器 ip 的 d 段代替伺服器,具體的 ip 請參考架構圖;

如果伺服器在不同機房,用伺服器 ip 的 c 段 和 d 段代替伺服器,具體的 ip 請參考架構圖;

每個場景給出方法,但不會詳細地給出每一步執行什麼命令,因為一方面,這會導致文章過長;另一方面,我認為只要知道方法,具體的做法就會迎面撲來的,只取決於掌握知識的程度和獲取資訊的能力;

實戰過程中的注意事項請參考第五節。

遵循從易到難的思路,我們從簡單的結構入手。a 專案,原本是一主一從結構。101 是主節點,102 是從節點。因業務需要,把 102 從節點遷移至 103,架構圖如圖一。102 從節點的資料容量過大,不能使用 mysqldump 的形式備份。和研發溝通後,形成一致的方案。

圖一 一主一從結構遷移從庫架構圖

具體做法是這樣:

我們知道一主一從只遷移從庫怎麼做之後,接下來看看怎樣同時遷移主從節點。因不同業務同時訪問同一伺服器,導致單個庫壓力過大,還不便管理。於是,打算將主節點 101 和從節點 102 同時遷移至新的機器 103 和 104,103 充當主節點,104 充當從節點,架構圖如圖二。此次遷移只需要遷移指定庫,這些庫容量不是太大,並且可以保證資料不是實時的。

圖二 一主一從結構遷移指定庫架構圖

具體的做法如下:

接下來看看一主一從結構雙邊遷移指定庫怎麼做。同樣是因為業務共用,導致伺服器壓力大,管理混亂。於是,打算將主節點 101 和從節點 102 同時遷移至新的機器 103、104、105、106,103 充當 104 的主節點,104 充當 103 的從節點,105 充當 106 的主節點,106 充當 105 的從節點,架構圖如圖三。此次遷移只需要遷移指定庫,這些庫容量不是太大,並且可以保證資料不是實時的。我們可以看到,此次遷移和場景二很類似,無非做了兩次遷移。

圖三 一主一從結構雙邊遷移指定庫架構圖

具體的做法如下:

接下來看看一主一從結構完整遷移主從怎麼做。和場景二類似,不過此處是遷移所有庫。因 101 主節點 io 出現瓶頸,打算將主節點 101 和從節點 102 同時遷移至新的機器 103 和 104,103 充當主節點,104 充當從節點。遷移完成後,以前的主節點和從節點廢棄,架構圖如圖四。此次遷移是全庫遷移,容量大,並且需要保證實時。這次的遷移比較特殊,因為採取的策略是先替換新的從庫,再替換新的主庫。所以做法稍微複雜些。

圖四 一主一從結構完整遷移主從架構圖

具體的做法是這樣:

業務遷移之前,斷掉 103 和 101 的同步關係;

做完上述步驟,可以和研發協調,把 101 的讀寫業務切回 102,讀業務切到 104。需要注意的是,此時 101 和 103 均可以寫,需要保證 101 在沒有寫入的情況下切到 103,可以使用 flush tables with read lock 鎖住 101,然後業務切到 103。注意,一定要業務低峰執行,切記;

切換完成後,觀察業務狀態;

如果業務沒有問題,證明遷移成功。

接下來看看雙主結構跨機房遷移怎麼做。某專案出於容災考慮,使用了跨機房,採用了雙主結構,雙邊均可以寫。因為磁碟空間問題,需要對 a 地的機器進行替換。打算將主節點 1.101 和從節點 1.102 同時遷移至新的機器 1.103 和 1.104,1.103 充當主節點,1.104 充當從節點。b 地的 2.101 和 2.102 保持不變,但遷移完成後,1.103 和 2.101 互為雙主。架構圖如圖五。因為是雙主結構,兩邊同時寫,如果要替換主節點,單方必須有節點停止服務。

圖五 雙主結構跨機房遷移架構圖

具體的做法如下:

接下來我們看看多例項跨機房遷移證明做。每台機器的例項關係,我們可以參考圖六。此次遷移的目的是為了做資料修復。在 2.117 上建立 7938 和 7939 例項,替換之前資料異常的例項。因為業務的原因,某些庫只在 a 地寫,某些庫只在 b 地寫,所以存在同步過濾的情況。

圖六 多例項跨機房遷移架構圖

具體的做法如下:

介紹完不同場景的遷移方案,需要注意如下幾點:

在 mysql 遷移實戰中,有如下技巧可以使用:

本文從為什麼要遷移講起,接下來講了遷移方案,然後講解了不同場景下的遷移實戰,最後給出了注意事項以及實戰技巧。歸納起來,也就以下幾點:

第一,遷移的目的是讓業務平穩持續地執行;

第二,遷移的核心是怎麼延續主從同步,我們需要在不同伺服器和不同業務之間找到方案;

第三,業務切換需要考慮不同 mysql 伺服器之間的許可權問題;需要考慮不同機器讀寫分離的順序以及主從關係;需要考慮跨機房呼叫對業務的影響。

讀者在實施遷移的過程中,可以參考此文提供的思路。但怎樣保證每個操作正確無誤地執行,還需要三思而後行。

不同場景下 MySQL 的遷移方案

五 注意事項 六 技巧 七 總結 mysql 遷移是 dba 日常維護中的乙個工作。遷移,究其本義,無非是把實際存在的物體挪走,保證該物體的完整性以及延續性。就像柔軟的沙灘上,兩個天真無邪的小孩,把一堆沙子挪向其他地方,鑄就內心神往的城堡。生產環境中,有以下情況需要做遷移工作,如下 一句話,遷移工作...

不同場景下 MySQL 的遷移方案

五 注意事項 六 技巧 七 總結 mysql 遷移是 dba 日常維護中的乙個工作。遷移,究其本義,無非是把實際存在的物體挪走,保證該物體的完整性以及延續性。就像柔軟的沙灘上,兩個天真無邪的小孩,把一堆沙子挪向其他地方,鑄就內心神往的城堡。生產環境中,有以下情況需要做遷移工作,如下 一句話,遷移工作...

MySQL 學習 不同場景下技術抉擇

在生產環境中,我們往往需要冗餘節點,也就是避免線上事故的產生。場景對應行業 解決方案 讀多寫少 電商 新聞 論壇 mysql nosql 寫多讀少 滴滴 校園成績 低價值資料 使用nosql儲存 值資料 使用tokudb來儲存 寫多讀多 借助redis,nosql等解決方法 綜合對比之下,建議選擇 ...