知識星球AWS RDS被強制升級是個無奈的事情，版本不支援，而被強制升級會影響業務可用性。與其被動強制升級，不如制定主動升級戰略。本文給大家介紹AWS RDS版本升級的最佳實踐，為作者嘔心泣血之作，整理至此希望可以幫助到大家。
1. AWS RDS的升級週期說明
根據亞馬遜的檔案 Amazon RDS FAQs上的說明，AWS RDS的大版本，至少能支援3年，小版本至少會支援1年。
根據和AWS的交流得知，一般社群基本版本釋出約5個月之後，AWS會釋出基於AWS的RDS。
因此，AWS的RDS升級週期是，待社群版本釋出後，約5個月，AWS釋出對應的版本，每個大版本至少支援3年，每個小版本至少支援1年。
2. AWS RDS的版本過期的後果
根據亞馬遜的檔案 Amazon RDS FAQs上的說明，當某個大版本或者小版本，過了亞馬遜的服務支援期，亞馬遜會提前提醒客戶（大版本提前6個月提醒，小版本提前3個月提醒），在提醒期過後，AWS會強制自動升級資料庫到最新的版本（即使客戶選擇的是關閉了自動小版本升級）。升級的過程，應用程式無法連線資料庫，造成業務影響。
- 註1：無論大版本，還是小版本，一旦過了亞馬遜的服務支援期，都會面臨強制升級的過程。
- 註2：小版本的升級過程，會包含備份，升級，再次備份。經驗值是第一次備份和最後一次備份，不影響業務正常訪問，升級資料庫的過程，影響業務正常訪問。整個升級的過程，大約30分鐘，其中影響業務訪問的時間為3分半鐘。但具體的業務影響時間，以實際測試為準。
- 註3：小版本在提醒期的deadline來之前的一週，已經不能對資料庫做任何modify的操作，包括搭建replica或者更改維護視窗。但是可以從備份的snapshot還原出來一個資料庫，用於測試升級的時長。
- 註4：小版本升級步驟是先升級從庫，再升級主庫。
3. 內部升級步驟解析
即：
a). 在升級前，做一次快照，註意這個快照的時間，和資料庫的大小的有關。
b). 進行slow shutdown，即set global innodb_fast_shutdown=0然後進行shutdown。由於設定了slow shutdown，因此dirty buffer會刷到磁碟上+insert buffer 也會刷到磁碟上（即system tablespace，ibdata1中）+full purge（即清理無用的undo頁）
c). 將mysql掛載到新的儲存引擎下，並且禁止遠端網路訪問；
d). 執行mysql_upgrade程式，升級資料字典。
e). 執行RDS特殊的一些指令碼，以便升級RDS封裝的表和儲存過程。
f). 重啟實體，開放網路遠端連線。
- 註1，在某些情況下，mysql_upgrade這個步驟會物理的重建表，表的大小會影響升級時間，所以實際升級的時間，需要以測試為準。如 MySQL 5.6.4 升級到5.7版本，因為 5.6.4 版本中的TIME, DATETIME, 和TIMESTAMP型別的儲存有改變，升級的時候，需要重建表。
- 註2，由於大版本不能跨大版本升級，如升級MySQL 5.5.46到5.7.19，不能直接升級，需要先將5.5.46升級到5.6，如5.6.37，再升級到5.7.19。因此業務受影響的時間，是兩次升級的時間。而不是一次。故不做大版本的交替升級。如分成5.5 升級 5.7，5.4升級5.6。
4. 版本釋出路線圖
根據社群釋出的版本時間，和AWS已經釋出的版本的時間，我們可以作出下麵的釋出路線圖。
MySQL：
PostgreSQL：
- 註1，最開始的淺綠色表示社群版第一版的釋出時間，後面的灰色，表示社群版基於第一版之後的小版本GA的時間，而其對應的AWS釋出的版本是彩色的。
- 註2，通常情況，AWS小版本至少支援一年（即12個月），但是有些小版本，AWS已經支援超過了12個月，有可能會隨時終止支援，所以我畫到了截止當前時間（2018年10月），後面的時間沒有繼續畫。（即沒有畫的不表示不支援，只是表示AWS版本釋出超過了12個月，在此之後可能會被終止支援而強制下線）
5. 升級最佳實踐
5.1. 大版本升級：
a). 先建立2個replica實體；
b). 升級其中一個實體到高版本，此時，還保持著主從的同步關係；
c).建立dms實體，配置好源和標的的endpoint，和建立好task，註意建立task時選擇changes only，並且取消 Start task on create的勾勾。
d). 業務中斷開始，將新建的replica實體提升為主庫；
d). 點選dms的task中的start ，等待其完成全量資料庫的對比，開始準備同步增量資料；
e). 切換應用連線到高版本的資料庫；
- 註1，從5.6.4以下的版本升級到5.6.4之後，需要alter table table_name force，重建表，才能使用online ddl的方式create index。
- 註2，大版本升級，需要驗證應用程式的效能，需要抓取至少一週的SQL，進行sql replay看效能的變化。
- 註3，升級之後，為了減少物理讀，儘快的將更多的資料載入到記憶體，可以用mysqldump做prewarm
- 註4，減少downtime，其中一個步驟是dms點選task的start進行全量資料的校對，如果加大主庫的IOPS，有助於提高該步驟的速度。（該步驟是業務停機操作的，因此減少該步驟的時間，等於減少停業務時間）。
aws mysql major version upgrade best practise.pdf
下載連結：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/
5.2. 小版本升級：
方法一：
a). 先建立replica實體，或直接使用現有的replica實體；
b). 升級replica實體到高版本，此時，還保持著主從的同步關係；
c). 業務中斷開始，將高版本的replica實體提升為主庫；
d). 切換應用連線到高版本的資料庫。應用的連線串配置，可以提前配置好，重啟應用即可；
aws mysql minor version upgrade best practise.pdf
下載連結：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/
方法二：
a). 先升級replica實體到高版本，這是所有AWS升級到必要前提，即必須先升級從庫；
b). 中斷業務和資料庫之間的連線，開始升級主庫；
c). 將主庫升級到高版本；
d). 恢復應用連線；
aws mysql minor version upgrade best practise_2.pdf
下載連結：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/
- 註1，方法一是AWS推薦的方案，但是方案二，對於小系統也是非常合適的。
- 註2，方法一的應用影響時間，是提升從庫為主庫的時間+應用重啟的時間。根據我們的某個資料庫的測試，提升的時間，大約是3分鐘02秒。加上應用重啟時間，也大約是3分半鐘。
- 註3，方法二，我們的某個資料庫測試資料是，整體的升級時間大約是34分鐘（因為包含了升級前資料庫做backup和升級完成後做backup，這都是升級過程中，AWS自己做的），而這34分鐘，並不是應用都不可用，在做資料庫backup時，資料庫還是可以用的，真正業務不能連資料庫的時間，是3分32秒。
- 註4，兩個方法，服務不可用的時間都差不多，都是大約3分半鐘。但是方法一有個風險，就是如果是因為需要強制升級小版本，已經快到升級的維護時間，且已經是deadline的維護時間，那麼雖然我們沒有去動主庫，但萬一失敗需要切換回主庫，而強制升級的時間又到了，觸發強制升級，那麼此時就是一個不可控的狀態了。因此我們還是選擇了方法二。
- 註5，最終應該選擇哪個方法，還是要依賴實際做升級測試的演練情況而定。
6. 總結
因此，我們可以制定如下的主動升級戰略：
(1). 禁止所有的小版本自動升級；
(2). 根據上面的所述，規定今後MySQL的新安裝版本的為5.7.23；
(3). 在一年內，對於之前MySQL 5.5版本，小版本統一過渡到5.5.61，MySQL 5.6版本，小版本統一過渡到5.6.41。這個可以避免MySQL的小版本因為不被支援導致強制升級，並且這2個版本的下一次強制升級時間，至少是在2019年9月之後。（pg類似指導思路）；
(4). 在一年內，對於之前的MySQL 5.5版本升級到5.6版本；在兩年內，對於MySQL 5.6版本，升級到5.7版本；在兩到三年內，統一到MySQL 8.0版本。解決由於多版本共存，導致運維難度增加的問題。（pg類似指導思路）；
(5). 後續的版本升級，將會按照1年一升小版本，3年一升大版本的進度推進，以符合AWS RDS的版本支援規則。
作者：何劍敏，某無人機公司運維部，資料庫架構師，負責公司雲上和雲下資料庫的架構、規劃和運維，專註於整體運維的思路，發揮平臺效應，實現雲上和雲下資料庫的統一運維。
朋友會在“發現-看一看”看到你“在看”的內容