[TOC] ## 停服務方案 1. 站點掛一個公告“為了為廣大用戶提供更好的服務，本站點/游戲將在今晚00:00-2:00之間升級，屆時將不能登錄，用戶周知” 2. 停服務 3. 新建y個庫，做好高可用 4. 數據遷移，重新分布，寫一個數據遷移程序，從x個庫里導入到y個庫里，路由規則由%x升級為%y 5. 修改服務配置，原來x行配置升級為y行 6. 重啟服務，連接新庫重新對外提供服務 整個過程中，最耗時的是第四步數據遷移。 回滾方案： 如果數據遷移失敗，或者遷移后測試失敗，則將配置改回x庫，恢復服務，改天再掛公告。 **方案優點**：簡單 **方案缺點**： 1. 停服務，不高可用 2. 技術同學壓力大，所有工作要在規定時間內做完，根據經驗，壓力越大約容易出錯（這一點很致命） 3. 如果有問題第一時間沒檢查出來，啟動了服務，運行一段時間后再發現有問題，難以回滾，需要回檔，可能會丟失一部分數據 ## 秒級平滑方案(推薦) **成倍擴容，避免數據遷移**  改為  主要修改兩處： 1. 數據庫實例所在的機器做雙虛ip，原來%2=0的庫是虛ip0，現在增加一個虛ip00，%2=1的另一個庫同理 1. 修改服務的配置（不管是在配置文件里，還是在配置中心），將2個庫的數據庫配置，改為4個庫的數據庫配置，修改的時候要注意舊庫與辛苦的映射關系： ``` %2=0的庫，會變為%4=0與%4=2； %2=1的部分，會變為%4=1與%4=3； ``` 這樣修改是為了保證，拆分后依然能夠路由到正確的數據 ### reload配置，實例擴容  服務層reload配置有這么幾種方式： 1. 比較原始的，重啟服務，讀新的配置文件 2. 高級一點的，配置中心給服務發信號，重讀配置文件，重新初始化數據庫連接池 reload之后，數據庫的實例擴容就完成了,對服務的正確性和可用性完全沒有影響 **但是** 1. 即使%2尋庫和%4尋庫同時存在，也不影響數據的正確性，因為此時仍然是雙主數據同步的 2. 服務reload之前是不對外提供服務的，冗余的服務能夠保證高可用 完成了實例的擴展，會發現**每個數據庫的數據量依然沒有下降**，所以第三個步驟還要做一些收尾工作 ### 收尾工作，數據收縮  有這些一些收尾工作： 1. 把雙虛ip修改回單虛ip 1. 解除舊的雙主同步，讓成對庫的數據不再同步增加 1. 增加新的雙主同步，保證高可用 1. 刪除掉冗余數據，例如：ip0里%4=2的數據全部干掉，只為%4=0的數據提供服務啦 這樣下來，每個庫的數據量就降為原來的一半，數據收縮完成