MySQL數據庫機房裁撤問題總結

背景：公司某一機房須要裁撤，涉及到大量DB服務器，須要在裁撤截止日期之前完成業務的平滑遷移和設備退還工做。

歷時2個多月，經歷了設備梳理、裁撤資源評估、裁撤資源申請、裁撤DB部署、裁撤DB業務關係梳理、裁撤DB合併協調、裁撤DB數據遷移、裁撤DB切換、設備下架和退還等流程後，終於將組內涉及到的DB都裁撤完成。裁撤期間遇到不少問題，總結一下，但願對你們有幫助。

1、裁撤遇到的問題

一、存在着很老的版本好比4.一、5.5的版本

二、表字段使用系統關鍵字帶來的兼容性問題

三、表沒有主鍵，致使從機有的時候延遲很大（row format）

四、數據庫中存在大量的MYISAM的表

五、部分實例數據量很大，超過1T

六、項目經久失修，找不到負責人

七、沒有名字服務或者proxy，裁撤須要業務修改IP，如何作到平滑切換

八、用於裁撤的資源不多

歷時2個多月，經歷了設備梳理、裁撤資源評估、裁撤資源申請、裁撤DB部署、裁撤DB業務關係梳理、裁撤DB合併協調、裁撤DB數據遷移、裁撤DB切換、設備下架和退還等流程後，終於將組內涉及到的DB都裁撤完成。期間不只僅將各個業務梳理清楚，而且對裁撤實例進行了清理和合並，僅用12臺設備就完成了所有實例的遷移，而且實現0故障裁撤。裁撤期間遇到多個問題，總結一下，但願對你們有幫助。

2、問題解決方法論

一、系統思惟

從全局的角度去看待遇到的問題，解決問題的時候不要只盯着某一個出問題的點，而應該站在更高的維度去思考解決方案。

二、資源整合

三、共贏思惟

裁撤是一項須要運維、研發、資源、質量等同事一塊兒協做的事情，咱們目標就是爲了業務平滑進行遷移和切換，咱們在作事情的時候，要多從共贏思惟中入手。其實本質就是要嘗試站在對方的角度思考問題，天然更能找到共贏的解決方案。

3、解決方案

一、針對版本問題的解決方案

將DB所有遷移到mysql 5.7版本，遷移數據分爲3步便可解決絕大部分的兼容性問題

a、只遷移業務數據，不mysql庫數據

b、遷移權限

c、作主從同步

針對4.1的同步不兼容的問題，因爲業務改動小，採用了的方案爲：

直接解析binlog將新產生的數據同步到新的DB上，屢次迭代，確保DB的差距最小後，直接停掉老DB，將少許新增的binlog經過工具同步到新DB上，並啓用端口轉發，將新的請求轉發到新DB，停機時間1分鐘之內。後面再讓業務平滑修改業務到新的DB上。

二、針對表字段使用系統關鍵字的解決方案

業務表使用系統關鍵字在mysql 5.7中會人爲SQL語法錯誤，從而致使sql執行失敗，有2個解決方案：

a、修改表的字段，兼容mysql 5.7（這個方案會致使業務側須要修改大量的代碼）

b、對字段的全部操做都加上反引號（這個方案對業務影響小，咱們採用的就是這個方式）

三、針對表沒有主鍵和MYISAM表的問題

針對表沒有主鍵和含有不少MYISAM表的問題，爲了方便管理，對裁撤的實例都進行梳理，而且在裁撤過程當中完成改造。長痛不如短痛。

沒有主鍵的解決方案

和業務溝通，統一在新實例中增長主鍵（現存字段）

MYISAM的解決方案

和業務溝通，統一在新實例將MYISAM表所有修改成innodb

四、針對項目經久失修的問題，只能經過抓包肯定對應的負責人，這裏的梳理工做確實很是繁雜；

五、針對實例數據量很大的解決方案

因爲設計到版本升級，沒法採用物理備份的方式進行，所以採用的是mydumper多線程備份的方式，導入的時候，將mysql相關的表所有移除。另外導入的時候不要記錄binlog，新DB主從都導入（不要作好主從後，只在主機上導入），或者在主機導入完成後，直接經過拷貝文件的方式作從機。

六、針對沒有名字服務或者proxy，作到平滑遷移的解決方案

以前老的DB沒有名字服務和proxy，若是要作切換，須要業務側去修改各個server的配置，因爲項目經久失修，大部分初始開發人員基本都已經離職或者轉崗，很容易出現修改遺漏，如何實現平滑遷移是重點要考慮的問題，咱們採用的方案是使用端口轉發的方式，端口轉發完成後，業務就能夠從容地去修改業務的配置了。使用端口轉發有以下幾種常見的方式：

a、使用iptables進行轉發

優勢是不須要停mysql，能夠作到真正的平滑遷移；缺點是處於安全考慮，公司的linux機器都沒有加載nat模塊，老系統若是要加載nat模塊須要編譯內核

b、使用ssh進行端口轉發

優勢是一條命令便可完成，很是方便，也不須要作改造；缺點是須要停mysql，會形成短暫的業務中斷；

c、使用haproxy進行端口轉發

缺點是須要額外部署和配置haproxy，也須要停掉mysql，會形成短暫的業務中斷；

d、使用lvs進行端口轉發

缺點是須要額外安裝和配置lvs

通過綜合考慮，咱們選擇了經過ssh端口轉發的方案。範例：

ssh -f -N -g -L3306:newDBip:3306 root@localip

注意：有部分系統ssh命令不支持-N參數，去掉-N參數便可。此外還須要注意的是須要給老DB的機器進行受權，不然會因爲權限問題帶來訪問失敗的狀況。

七、用於裁撤的資源不多的解決方案

機房裁撤的時候，資源側給的裁撤資源確定不會按照置換比1：1置換，而DB數據量通常都比較大。咱們採起的方案是清理能清理的數據、合併能合併的實例。

4、DB裁撤問題的思考

經歷一次裁撤，真的有種「不會再愛了」的感受，每次都很是痛苦。要規避這種痛苦，只有從架構上去規避這種業務直連DB帶來的問題。能夠採用netagent/名字服務/l5等。在後面的DB接入中，須要將此種需求歸入到數據庫的准入標準中。

做者：飛鴻無痕 連接：https://www.jianshu.com/p/5e55d29dbd57 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。