本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
使用零停機時間修補
執行資料 Aurora MySQL 資料庫叢集的升級牽涉到資料庫關閉和升級時發生中斷的可能性。根據預設，如果您在資料庫忙碌時開始升級，則會遺失資料庫叢集正在處理的所有連線和交易。如果您要等到資料庫閒置才執行升級，就可能必須等待很長時間。
零停機時間修補 (ZDP) 功能以最佳作法為基礎，試圖在整個 Aurora MySQL 升級過程維持用戶端正常連線。如果 ZDP 成功完成，即可保留應用程式工作階段，資料庫引擎也會在升級期間重新啟動。資料庫引擎重新啟動可能會導致輸送量下降，持續時間為數秒到一分鐘左右。
ZDP 不適用於下列項目：
-
作業系統 (OS) 修補程式與升級
-
主要版本升級
ZDP 適用於所有支援的 Aurora MySQL 版本和資料庫執行個體類別。
Aurora Serverless v1 或 Aurora 全球資料庫不支援 ZDP。
注意
建議您在開發、測試伺服器或其他非生產伺服器時，僅使用 T 資料庫執行個體類別。如需詳細了解 T 執行個體類別，請參閱 使用 T 執行個體類別進行開發和測試。
您可以在 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 參考手冊。 -
來自
INFORMATION_SCHEMA和PERFORMANCE_SCHEMA資料表的診斷資訊。這項診斷資訊也會出現在SHOW PROFILE和SHOW PROFILES等命令的輸出中。
Events (事件) 頁面會報告下列與零停機時間重新啟動相關的活動：
-
嘗試在零停機時間的情況下升級資料庫。
-
嘗試在零停機時間的情況下升級資料庫已完成。事件會報告程序所花費的時間。此事件也會報告重新啟動期間保留的連線數目，以及已中斷的連線數目。您可以查閱資料庫錯誤日誌，瞭解重新啟動期間所發生情況的相關詳細資訊。
