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

AWS RDS被強制升級是個無奈的事情，版本不支持，而被強制升級會影響業(yè)務可用性。與其被動強制升級，不如制定主動升級戰(zhàn)略。本文給大家介紹AWS RDS版本升級的最佳實踐，為作者嘔心泣血之作，整理至此希望可以幫助到大家。

1. AWS RDS的升級周期說明

根據(jù)亞馬遜的文檔 Amazon RDS FAQs上的說明，AWS RDS的大版本，至少能支持3年，小版本至少會支持1年。

根據(jù)和AWS的交流得知，一般社區(qū)基本版本發(fā)布約5個月之后，AWS會發(fā)布基于AWS的RDS。

因此，AWS的RDS升級周期是，待社區(qū)版本發(fā)布后，約5個月，AWS發(fā)布對應的版本，每個大版本至少支持3年，每個小版本至少支持1年。

2. AWS RDS的版本過期的后果

根據(jù)亞馬遜的文檔 Amazon RDS FAQs上的說明，當某個大版本或者小版本，過了亞馬遜的服務支持期，亞馬遜會提前提醒客戶（大版本提前6個月提醒，小版本提前3個月提醒），在提醒期過后，AWS會強制自動升級數(shù)據(jù)庫到最新的版本（即使客戶選擇的是關(guān)閉了自動小版本升級）。升級的過程，應用程序無法連接數(shù)據(jù)庫，造成業(yè)務影響。

• 注1：無論大版本，還是小版本，一旦過了亞馬遜的服務支持期，都會面臨強制升級的過程。

• 注2：小版本的升級過程，會包含備份，升級，再次備份。經(jīng)驗值是第一次備份和最后一次備份，不影響業(yè)務正常訪問，升級數(shù)據(jù)庫的過程，影響業(yè)務正常訪問。整個升級的過程，大約30分鐘，其中影響業(yè)務訪問的時間為3分半鐘。但具體的業(yè)務影響時間，以實際測試為準。

• 注3：小版本在提醒期的deadline來之前的一周，已經(jīng)不能對數(shù)據(jù)庫做任何modify的操作，包括搭建replica或者更改維護窗口。但是可以從備份的snapshot還原出來一個數(shù)據(jù)庫，用于測試升級的時長。

• 注4：小版本升級步驟是先升級從庫，再升級主庫。

  
  

3. 內(nèi)部升級步驟解析

即：
a). 在升級前，做一次快照，注意這個快照的時間，和數(shù)據(jù)庫的大小的有關(guān)。
b). 進行slow shutdown，即set global innodb_fast_shutdown=0然后進行shutdown。由于設置了slow shutdown，因此dirty buffer會刷到磁盤上+insert buffer 也會刷到磁盤上（即system tablespace，ibdata1中）+full purge（即清理無用的undo頁）
c). 將mysql掛載到新的存儲引擎下，并且禁止遠程網(wǎng)絡訪問；
d). 運行mysql_upgrade程序，升級數(shù)據(jù)字典。
e). 運行RDS特殊的一些腳本，以便升級RDS封裝的表和存儲過程。
f). 重啟實例，開放網(wǎng)絡遠程連接。

• 注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。因此業(yè)務受影響的時間，是兩次升級的時間。而不是一次。故不做大版本的交替升級。如分成5.5 升級 5.7，5.4升級5.6。

  
  

4. 版本發(fā)布路線圖

根據(jù)社區(qū)發(fā)布的版本時間，和AWS已經(jīng)發(fā)布的版本的時間，我們可以作出下面的發(fā)布路線圖。

MySQL：

PostgreSQL：

• 注1，最開始的淺綠色表示社區(qū)版第一版的發(fā)布時間，后面的灰色，表示社區(qū)版基于第一版之后的小版本GA的時間，而其對應的AWS發(fā)布的版本是彩色的。

• 注2，通常情況，AWS小版本至少支持一年（即12個月），但是有些小版本，AWS已經(jīng)支持超過了12個月，有可能會隨時終止支持，所以我畫到了截止當前時間（2018年10月），后面的時間沒有繼續(xù)畫。（即沒有畫的不表示不支持，只是表示AWS版本發(fā)布超過了12個月，在此之后可能會被終止支持而強制下線）

5. 升級最佳實踐

5.1. 大版本升級：

a). 先創(chuàng)建2個replica實例；
b). 升級其中一個實例到高版本，此時，還保持著主從的同步關(guān)系；
c).創(chuàng)建dms實例，配置好源和目標的endpoint，和創(chuàng)建好task，注意創(chuàng)建task時選擇changes only，并且取消 Start task on create的勾勾。
d). 業(yè)務中斷開始，將新建的replica實例提升為主庫；
d). 點擊dms的task中的start ，等待其完成全量數(shù)據(jù)庫的對比，開始準備同步增量數(shù)據(jù)；
e). 切換應用連接到高版本的數(shù)據(jù)庫；

• 注1，從5.6.4以下的版本升級到5.6.4之后，需要alter table table_name force，重建表，才能使用online ddl的方式create index。

• 注2，大版本升級，需要驗證應用程序的性能，需要抓取至少一周的SQL，進行sql replay看性能的變化。

• 注3，升級之后，為了減少物理讀，盡快的將更多的數(shù)據(jù)加載到內(nèi)存，可以用mysqldump做prewarm

• 注4，減少downtime，其中一個步驟是dms點擊task的start進行全量數(shù)據(jù)的校對，如果加大主庫的IOPS，有助于提高該步驟的速度。（該步驟是業(yè)務停機操作的，因此減少該步驟的時間，等于減少停業(yè)務時間）。

  
  

aws mysql major version upgrade best practise.pdf

下載鏈接：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/

5.2. 小版本升級：

方法一：
a). 先創(chuàng)建replica實例，或直接使用現(xiàn)有的replica實例；
b). 升級replica實例到高版本，此時，還保持著主從的同步關(guān)系；
c). 業(yè)務中斷開始，將高版本的replica實例提升為主庫；
d). 切換應用連接到高版本的數(shù)據(jù)庫。應用的連接串配置，可以提前配置好，重啟應用即可；

aws mysql minor version upgrade best practise.pdf

下載鏈接：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/

方法二：
a). 先升級replica實例到高版本，這是所有AWS升級到必要前提，即必須先升級從庫；
b). 中斷業(yè)務和數(shù)據(jù)庫之間的連接，開始升級主庫；
c). 將主庫升級到高版本；
d). 恢復應用連接；

aws mysql minor version upgrade best practise_2.pdf

下載鏈接：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/

• 注1，方法一是AWS推薦的方案，但是方案二，對于小系統(tǒng)也是非常合適的。

• 注2，方法一的應用影響時間，是提升從庫為主庫的時間+應用重啟的時間。根據(jù)我們的某個數(shù)據(jù)庫的測試，提升的時間，大約是3分鐘02秒。加上應用重啟時間，也大約是3分半鐘。

• 注3，方法二，我們的某個數(shù)據(jù)庫測試數(shù)據(jù)是，整體的升級時間大約是34分鐘（因為包含了升級前數(shù)據(jù)庫做backup和升級完成后做backup，這都是升級過程中，AWS自己做的），而這34分鐘，并不是應用都不可用，在做數(shù)據(jù)庫backup時，數(shù)據(jù)庫還是可以用的，真正業(yè)務不能連數(shù)據(jù)庫的時間，是3分32秒。

• 注4，兩個方法，服務不可用的時間都差不多，都是大約3分半鐘。但是方法一有個風險，就是如果是因為需要強制升級小版本，已經(jīng)快到升級的維護時間，且已經(jīng)是deadline的維護時間，那么雖然我們沒有去動主庫，但萬一失敗需要切換回主庫，而強制升級的時間又到了，觸發(fā)強制升級，那么此時就是一個不可控的狀態(tài)了。因此我們還是選擇了方法二。

• 注5，最終應該選擇哪個方法，還是要依賴實際做升級測試的演練情況而定。

6. 總結(jié)

因此，我們可以制定如下的主動升級戰(zhàn)略：

(1). 禁止所有的小版本自動升級；

(2). 根據(jù)上面的所述，規(guī)定今后MySQL的新安裝版本的為5.7.23；

(3). 在一年內(nèi)，對于之前MySQL 5.5版本，小版本統(tǒng)一過渡到5.5.61，MySQL 5.6版本，小版本統(tǒng)一過渡到5.6.41。這個可以避免MySQL的小版本因為不被支持導致強制升級，并且這2個版本的下一次強制升級時間，至少是在2019年9月之后。（pg類似指導思路）；

(4). 在一年內(nèi)，對于之前的MySQL 5.5版本升級到5.6版本；在兩年內(nèi)，對于MySQL 5.6版本，升級到5.7版本；在兩到三年內(nèi)，統(tǒng)一到MySQL 8.0版本。解決由于多版本共存，導致運維難度增加的問題。（pg類似指導思路）；

(5). 后續(xù)的版本升級，將會按照1年一升小版本，3年一升大版本的進度推進，以符合AWS RDS的版本支持規(guī)則。

作者：何劍敏，某無人機公司運維部，數(shù)據(jù)庫架構(gòu)師，負責公司云上和云下數(shù)據(jù)庫的架構(gòu)、規(guī)劃和運維，專注于整體運維的思路，發(fā)揮平臺效應，實現(xiàn)云上和云下數(shù)據(jù)庫的統(tǒng)一運維。