本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 使用零停機時間修補
<a name="AuroraMySQL.Updates.ZDP"></a><a name="zdp"></a>

執行資料 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 (事件)** 頁面會報告下列與零停機時間重新啟動相關的活動：
+ 嘗試在零停機時間的情況下升級資料庫。
+ 嘗試在零停機時間的情況下升級資料庫已完成。事件會報告程序所花費的時間。此事件也會報告重新啟動期間保留的連線數目，以及已中斷的連線數目。您可以查閱資料庫錯誤日誌，瞭解重新啟動期間所發生情況的相關詳細資訊。