本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 升級 Aurora MySQL 資料庫叢集的次要版本或修補程式層級
您可以使用下列方法來升級資料庫叢集的次要版本或修補資料庫叢集：
+ [透過修改引擎版本升級 Aurora MySQL](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md) (適用於 Aurora MySQL 第 2 版和第 3 版)
+ [啟用次要 Aurora MySQL 版本之間的自動升級](AuroraMySQL.Updates.AMVU.md)
如需零停機時間修補如何在升級程序期間減少中斷的相關資訊，請參閱[使用零停機時間修補](AuroraMySQL.Updates.ZDP.md)。
如需為 Aurora MySQL 資料庫叢集執行次要版本升級的相關資訊，請參閱下列主題。
**Topics**
+ [執行次要版本升級之前](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Aurora MySQL 的次要版本升級預先檢查](#AuroraMySQL.minor-upgrade-prechecks)
+ [透過修改引擎版本升級 Aurora MySQL](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [啟用次要 Aurora MySQL 版本之間的自動升級](AuroraMySQL.Updates.AMVU.md)
+ [使用零停機時間修補](AuroraMySQL.Updates.ZDP.md)
+ [替代藍/綠升級技術](#AuroraMySQL.UpgradingMinor.BlueGreen)
## 執行次要版本升級之前
建議您執行下列動作，以減少次要版本升級期間的停機時間：
+ Aurora 資料庫叢集維護應在低流量期間執行。使用 Performance Insights 來識別這些時段，以正確設定維護時段。如需 Performance Insights 的詳細資訊，請參閱[在 Amazon RDS 上使用 Performance Insights 監控資料庫負載](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)。如需資料庫叢集維護時段的詳細資訊，請參閱 [調整偏好的資料庫叢集維護時段](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora)。
+ 最佳實務是支援指數退避和抖動 AWS SDKs。如需詳細資訊，請參閱[指數退避和抖動](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)。
## Aurora MySQL 的次要版本升級預先檢查
當您開始次要版本升級時，Amazon Aurora 會自動執行預先檢查。
系統會強制執行這些前置檢查，您無法選擇略過這些檢查。前置檢查提供以下優勢：
+ 升級期間可避免非預期的停機時間。
+ 出現不相容情況時，Amazon Aurora 即會防止系統進行升級，並提供相關日誌讓您了解。如此，您就可以使用這些日誌來減少不相容情況，為資料庫做好升級的準備。如需移除不相容的詳細資訊，請參閱 MySQL 文件中的[準備您的安裝進行升級](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html)。
前置檢查會在系統將資料庫執行個體停止以進行升級前執行，意即前置檢查執行期間不會造成任何停機時間。如果預先檢查找到不相容，Aurora 會在資料庫執行個體停止前自動取消升級。Aurora 也會為不相容產生事件。如需 Amazon Aurora 事件的詳細資訊，請參閱 [使用 Amazon RDS 事件通知](USER_Events.md)。
Aurora 會在日誌檔案 `PrePatchCompatibility.log` 中記錄每個不相容的相關詳細資訊。在多數情況下，日誌項目包含修正不相容的 MySQL 文件連結。如需檢視日誌檔案的詳細資訊，請參閱[檢視並列出資料庫日誌檔案](USER_LogAccess.Procedural.Viewing.md)。
根據前置檢查的特性，這些檢查作業會分析資料庫中的物件。此分析會耗用資源，並增加升級完成的時間。
# 透過修改引擎版本升級 Aurora MySQL
升級 Aurora MySQL 資料庫叢集的次要版本會將額外的修正程式和新功能套用至現有叢集。
此類升級適用於原始版本和升級版本皆有相同 Aurora MySQL 主要版本 2 或 3 的 Aurora MySQL 叢集。此程序既快速又直接，因為它不涉及 Aurora MySQL 中繼資料的任何轉換或資料表資料的重組。
您可以使用 AWS 管理主控台、AWS CLI 或 RDS API 修改資料庫叢集的引擎版本，以執行此類升級。例如，如果您的叢集正在執行 Aurora MySQL 3.x，請選擇較高的 3.x 版本。
如果要針對 Aurora 全球資料庫執行次要升級，請先升級所有次要叢集，再升級主要叢集。
**注意**
若要執行次要版本升級至 Aurora MySQL 3.04.\$1 版及更新版本，或 2.12 \$1 版，請遵循下列操作：
從全域叢集移除所有次要區域。請遵循 [從 Amazon Aurora 全域資料庫中移除叢集](aurora-global-database-detaching.md) 中的步驟。
將主要區域的引擎版本升級至 3.04.\$1 或更新版本，或 2.12.\$1 版 (如適用)。請遵循 [To modify the engine version of a DB cluster](#modify-db-cluster-engine-version) 中的步驟。
將次要區域新增至全域叢集。請遵循 [將 AWS 區域 新增到 Amazon Aurora 全域資料庫](aurora-global-database-attaching.md) 中的步驟。
**修改資料庫叢集的引擎版本**
+ **使用主控台** – 修改叢集的屬性。在 **Modify DB cluster (修改資料庫叢集)** 視窗中，變更 **DB engine version (資料庫引擎版本)** 方塊中的 Aurora MySQL 引擎版本。如果您不熟悉修改叢集的一般程序，請遵循 [使用主控台、CLI 和 API 修改資料庫叢集](Aurora.Modifying.md#Aurora.Modifying.Cluster) 中的指示。
+ **透過使用 AWS CLI** – 呼叫 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI 命令，並在 `--db-cluster-identifier` 選項中指定資料庫叢集的名稱，在 `--engine-version` 選項中指定引擎版本。
例如，若要升級到 Aurora MySQL 3.04.1 版，請將 `--engine-version` 選項設為 `8.0.mysql_aurora.3.04.1`。指定 `--apply-immediately` 選項以立即更新資料庫叢集的引擎版本。
+ **使用 RDS API** – 呼叫 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API 操作，並在 `DBClusterIdentifier` 參數中指定資料庫叢集的名稱，在 `EngineVersion` 參數中指定引擎版本。將 `ApplyImmediately` 參數設為 `true`，以立即更新資料庫叢集的引擎版本。
# 啟用次要 Aurora MySQL 版本之間的自動升級
對於 Amazon Aurora MySQL 資料庫叢集，您可以指定 Aurora 會自動將資料庫叢集升級為新的次要版本。您可以透過設定資料庫叢集的 `AutoMinorVersionUpgrade` 屬性 (AWS 管理主控台 中的**自動次要版本升級**) 來執行此操作。
自動升級會在維護時段期間進行。如果資料庫叢集中的個別資料庫執行個體維護時段不同於叢集維護時段，則會優先考慮叢集維護時段。
自動次要版本升級不適用於下列類型的 Aurora MySQL 叢集：
+ 屬於 Aurora 全域資料庫一部分的叢集
+ 具有跨區域複本的叢集
中斷持續時間視工作負載、叢集大小、二進位記錄資料的數量，以及 Aurora 是否可使用零停機時間修補 (ZDP) 功能而定。Aurora 會重新啟動資料庫叢集，因此在繼續使用叢集之前，您可能會遇到短暫無法使用的狀況。特別是二進位日誌資料的數量會影響復原時間。資料庫執行個體會在復原期間處理二進位記錄資料。因此，大量的二進位記錄資料會增加復原時間。
**注意**
Aurora 僅在資料庫叢集中的所有資料庫執行個體皆已啟用 `AutoMinorVersionUpgrade` 設定時才會執行自動升級。如需了解如何設定它，以及套用於叢集和執行個體層級時如何運作，請參閱 [Aurora 資料庫叢集的自動次要版本升級](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU)。
然後，如果資料庫叢集執行個體的升級路徑存在，而次要資料庫引擎版本將 `AutoUpgrade` 設為 true，則會進行升級。`AutoUpgrade` 設定是動態的，並由 RDS 設定。
自動次要版本的升級會執行至預設次要版本。
您可以使用下列 CLI 命令來檢查 Aurora MySQL 叢集中所有資料庫執行個體的`AutoMinorVersionUpgrade`升級設定狀態。
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
此命令會產生類似下列的輸出：
```
[
{
"DBInstanceIdentifier": "db-t2-medium-instance",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-t2-small-original-size",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "instance-2020-05-01-2332",
"DBClusterIdentifier": "cluster-57-2020-05-01-4615",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
在此範例中，資料庫叢集 `cluster-57-2020-06-03-6411` 的**啟用自動次要版本升級**已關閉，因為叢集的其中一個資料庫執行個體已關閉此功能。
# 使用零停機時間修補
執行資料 Aurora MySQL 資料庫叢集的升級牽涉到資料庫關閉和升級時發生中斷的可能性。根據預設，如果您在資料庫忙碌時開始升級，則會遺失資料庫叢集正在處理的所有連線和交易。如果您要等到資料庫閒置才執行升級，就可能必須等待很長時間。
零停機時間修補 (ZDP) 功能以最佳作法為基礎，試圖在整個 Aurora MySQL 升級過程維持用戶端正常連線。如果 ZDP 成功完成，即可保留應用程式工作階段，資料庫引擎也會在升級期間重新啟動。資料庫引擎重新啟動可能會導致輸送量下降，持續時間為數秒到一分鐘左右。
ZDP 不適用於下列項目：
+ 作業系統 (OS) 修補程式與升級
+ 主要版本升級
ZDP 適用於所有支援的 Aurora MySQL 版本和資料庫執行個體類別。
Aurora Serverless v1 或 Aurora 全球資料庫不支援 ZDP。
**注意**
建議您在開發、測試伺服器或其他非生產伺服器時，僅使用 T 資料庫執行個體類別。如需詳細了解 T 執行個體類別，請參閱 [使用 T 執行個體類別進行開發和測試](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium)。
您可以在 MySQL 錯誤日誌中查看 ZDP 期間重要屬性的指標。您也可以在 AWS 管理主控台 中的 **Events** (事件) 頁面上，查看 Aurora MySQL 何時使用 ZDP 或選擇不使用 ZDP 的相關資訊。
在 Aurora MySQL 中，不論是否啟用二進位日誌複寫功能，Aurora 皆可執行零停機時間修補。若啟用二進位日誌複寫功能，Aurora MySQL 會在 ZDP 操作期間自動中斷與 binlog 目標的連線。Aurora MySQL 會在重新啟動完成後，自動重新連線到 binlog 目標並繼續複寫。
ZDP 也可與 Aurora MySQL 中的重新開機增強功能搭配使用。修補寫入器資料庫執行個體會同時自動修補讀取器。執行修補程式之後，Aurora 會恢復寫入器和讀取器資料庫執行個體上的連線。
若有以下情況，ZDP 便可能無法成功完成：
+ 長時間執行的查詢或交易正在進行中 如果 Aurora 可以在此情況下執行 ZDP，則會取消任何開啟的交易，但其連線會保留。
+ 暫存資料表、使用者鎖定或資料表鎖定正在使用中，例如資料定義語言 (DDL) 陳述式執行時。Aurora 會捨棄這些連線。
+ 存在擱置中的參數變更。
若因為一或多個上述條件而無執行 ZDP 的合適時段，修補作業會還原至標準行為。
雖然在成功的 ZDP 操作之後連線仍保持不變，但某些變數和功能會重新初始化。下列類型的資訊在零停機修補所造成的重新啟動時不會保留：
+ 全域變數。Aurora 會恢復工作階段變數，但它不會在重新啟動後恢復全域變數。
+ 狀態變數。特別是，引擎狀態報告的正常執行時間值會在使用 ZDR 或 ZDP 機制的重新啟動之後重設。
+ `LAST_INSERT_ID`.
+ 資料表的記憶體內 `auto_increment` 狀態。記憶體內的自動增量狀態會重新初始化。如需自動增量值的詳細資訊，請參閱 [MySQL 參考手冊](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization)。
+ 來自 `INFORMATION_SCHEMA` 和 `PERFORMANCE_SCHEMA` 資料表的診斷資訊。這項診斷資訊也會出現在 `SHOW PROFILE` 和 `SHOW PROFILES` 等命令的輸出中。
**Events (事件)** 頁面會報告下列與零停機時間重新啟動相關的活動：
+ 嘗試在零停機時間的情況下升級資料庫。
+ 嘗試在零停機時間的情況下升級資料庫已完成。事件會報告程序所花費的時間。此事件也會報告重新啟動期間保留的連線數目，以及已中斷的連線數目。您可以查閱資料庫錯誤日誌，瞭解重新啟動期間所發生情況的相關詳細資訊。
## 替代藍/綠升級技術
在某些情況下，您的首要目標是立即從舊叢集切換至升級的叢集。在這類情況下，您也可以使用多步驟程序，並排執行新舊叢集。在這裡，您會將舊叢集的資料複寫到新叢集，直至您準備好接管新叢集。如需詳細資訊，請參閱 [使用 Amazon Aurora 藍/綠部署進行資料庫更新](blue-green-deployments.md)。