五 注意事項
六 技巧
七 總結
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等解決方法 綜合對比之下，建議選擇 ...