今天對運維系統的MySQL架構做了下升級，從單點實例升級到了MGR跨機房集群。當然目前也是一個迭代的方案，后續的架構升級還需要持續的補充，算是一個開始吧。
首先運維系統建設也有一些日子了，已經支撐了不少線上的業務，所以從原來的測試版本逐步過渡到了一個正式的線上版本，系統優先級提高了，系統的高可用就是一個需要重點考慮的問題，如果說元數據的信息丟失了，我們無法恢復，那么這個修復的代價就非常高了。
當前系統的狀態如下：
目前在兩個機房存在兩臺服務器，彼此都是獨立的，分別負責了3個獨立的業務方向。
現在需要對9.208所在的機房數據庫做下架構升級，改造為MGR有一個硬性要求就是表需要有主鍵。對于xwiki業務的表因為是采用的一個開源版本，基于hibernate實現，我們無法保證這個數據庫的業務邏輯中對于自增列的使用場景和hibernate的完全匹配，基本上這個業務就是最小化運維，拿來能用即可，所以就不打算投入太多精力去調研這方面的需求匹配，所以經過權衡，在不影響已有的權限和業務的情況下，把xwiki業務分離出去，使得運維系統devopsdb的業務能夠直接升級到MGR架構環境下。
為了避免升級的時候，我們才開始部署MGR環境，我們需要預先搭建一套MGR環境，到時候需要導出線上數據，導入MGR環境。
準備的環境如下，尤其需要注意下圖中的端口，這是我們為了保持業務連接和權限不變，對于業務使用來說能夠透明一些。
線上環境升級時的架構如下，我們需要切換為MGR環境，原來環境的devopsdb數據可以備份出來就不再使用了，同時為了兼容和統一端口，119.221服務器上面的數據庫需要調整端口，從4306修改為4316.
調整后的的架構改進圖如下：
看起來簡單的需求，為了保證兼容和統一，需要做不少的工作來承接這個相對平滑的過程，目前采用的是單主的模式，在經過了反復測試之后，和同事一起做了下升級的完整過程，算是一個好的開始。
我們把整個過程分成了18個步驟,每個步驟都做了下時間統計，供參考。
MGR切換前工作
- MGR-4310修改increment_offset為3
- 檢查xwiki的數據庫配置和服務配置（Tomcat）
- 從mysql-4306導出devopsdb數據導入MGR-4310,評估導入時間，查看是否有導入錯誤
- MGR-4310切換測試
- Shutdown mysql_9.208-4310,預期切換到119.221-4310,測試寫入數據
- Startup mysql_9.208-4310,加入集群
- Shutdown mysql_119.221-4310,預期切換到mysql_9.208-4310
- MGR-4310端口切換測試，修改端口為4301 11:30確認是否可行
- 梳理字典表用戶，生成sql
- 正式切換
- 停止opsmange,xwiki服務
- Mysql_9.208-4306備份 mysqldump 備份devopsdb
- xwiki備份
- Shutdown Mysql-9.208-4306
- 修改mysql-9.208-4306為mysql-9.208-4308,降低buffer_pool配置
- 修改xwiki的數據庫配置為4308，啟動xwiki
- 切換MGR-4301為MGR-4306,修改buffer_pool配置，兩個節點都修改
- 啟動MGR-4306,恢復devopsdb的數據
- 測試工單流程和cmdb的數據情況，驗證升級的有效性。
整個過程還是比較緊湊的，中間碰到了不少的實戰問題，在有限的時間內推動完成還是挺不容易的。
