本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
使用零停機時間修補
執行 Aurora MySQL 資料庫叢集的升級，涉及資料庫關閉和升級時中斷的可能性。根據預設，如果您在資料庫忙碌時開始升級，則會遺失資料庫叢集正在處理的所有連線和交易。如果您要等到資料庫閒置才執行升級，就可能必須等待很長時間。
零停機時間修補 (ZDP) 功能會盡力透過 Aurora MySQL 升級保留用戶端連線。如果 ZDP 成功完成，則會保留應用程式工作階段，並在升級進行時重新啟動資料庫引擎。資料庫引擎重新啟動可能會導致輸送量下降，持續時間為數秒到一分鐘左右。
ZDP 不適用於下列項目：
-
作業系統 (OS) 修補程式與升級
-
主要版本升級
ZDP 適用於所有支援的 Aurora MySQL 版本和資料庫執行個體類別。
ZDP 不支援 Aurora Serverless v1 或 Aurora 全域資料庫。
注意
建議您在開發、測試伺服器或其他非生產伺服器時，僅使用 T 資料庫執行個體類別。如需詳細了解 T 執行個體類別，請參閱 使用 T 執行個體類別進行開發和測試。
您可以在我的SQL錯誤日誌ZDP中查看期間重要屬性的指標。您也可以ZDP在 的事件頁面上查看 Aurora MySQL 何時使用或ZDP選擇不使用 的相關資訊 AWS Management Console。
在 Aurora My 中SQL，無論是否啟用二進位日誌複寫，Aurora 都可以執行零停機時間修補程式。如果啟用二進位日誌複寫，Aurora MySQL 會在ZDP操作期間自動捨棄與 binlog 目標的連線。Aurora MySQL 會自動重新連線至 binlog 目標，並在重新啟動完成後繼續複寫。
ZDP 也可以與 Aurora My 中的重新開機增強功能搭配使用SQL。修補寫入器資料庫執行個體會同時自動修補讀取器。執行修補程式之後，Aurora 會恢復寫入器和讀取器資料庫執行個體上的連線。
ZDP 在下列情況下， 可能無法成功完成：
-
長時間執行的查詢或交易正在進行中 如果 Aurora 可以ZDP在這種情況下執行，則任何開啟的交易都會取消，但其連線會保留。
-
臨時資料表、使用者鎖定或資料表鎖定正在使用中，例如在執行資料定義語言 (DDL) 陳述式時。Aurora 會捨棄這些連線。
-
存在擱置中的參數變更。
如果因為一或多個這些條件而沒有適合執行的時段ZDP，修補會還原為標準行為。
雖然連線在操作成功後保持不變ZDP，但某些變數和功能會重新初始化。下列類型的資訊在零停機修補所造成的重新啟動時不會保留：
-
全域變數。Aurora 會恢復工作階段變數，但它不會在重新啟動後恢復全域變數。
-
狀態變數。特別是，引擎狀態回報的運作時間值會在使用 ZDR或 ZDP機制的重新啟動後重設。
-
LAST_INSERT_ID. -
資料表的記憶體內
auto_increment狀態。記憶體內的自動增量狀態會重新初始化。如需自動遞增值的詳細資訊，請參閱我的SQL參考手冊。 -
來自
INFORMATION_SCHEMA和PERFORMANCE_SCHEMA資料表的診斷資訊。這項診斷資訊也會出現在SHOW PROFILE和SHOW PROFILES等命令的輸出中。
Events (事件) 頁面會報告下列與零停機時間重新啟動相關的活動：
-
嘗試在零停機時間的情況下升級資料庫。
-
嘗試在零停機時間的情況下升級資料庫已完成。事件會報告程序所花費的時間。此事件也會報告重新啟動期間保留的連線數目，以及已中斷的連線數目。您可以查閱資料庫錯誤日誌，瞭解重新啟動期間所發生情況的相關詳細資訊。
