AWS RDS強制升級的應對之道——版本升級的最佳實踐

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的版本支援規則。

作者：何劍敏，某無人機公司運維部，資料庫架構師，負責公司雲上和雲下資料庫的架構、規劃和運維，專注於整體運維的思路，發揮平臺效應，實現雲上和雲下資料庫的統一運維。