適用於 MySQL 的 Azure 資料庫會執行定期維護，以協助保持受控資料庫的安全、穩定且最新狀態。 在維護期間，伺服器會取得新的功能、更新和修補檔。
重要事項
避免在適用於 MySQL 的 Azure 資料庫維護期間進行所有伺服器作業（修改、設定變更、啟動/停止）。 參與這些活動可能會導致可能影響伺服器效能和穩定性的無法預期結果。 等到維護結束後，再執行伺服器作業。
維護週期
下列各節說明維護類型。 如需每個維護更新需要之特定詳細數據，請參閱版本資訊。 這些附註提供維護期間所套用之更新的完整資訊，讓您了解並準備影響環境的任何變更。
附註
並非所有伺服器都必須在排程更新期間進行維護，無論是例行或關鍵。 Azure MySQL 小組會採用特定準則來判斷哪些伺服器需要維修。 此選擇性方法可確保維護既有效率又重要，可針對每個伺服器環境的獨特需求量身打造，並將生產停機時間降到最低。
常式維護
我們的標準維護週期不低於每 30 天一次。 此期間有助於確保系統穩定性和效能，同時將服務中斷降至最低。
重大維護
在某些情況下，例如需要部署緊急安全性修正或更新，對於維護可用性和數據完整性至關重要，我們可能會更頻繁地進行維護。 這些例外狀況有助於保護您的數據，並確保服務持續運作。
Virtual Canary 維護
Virtual Canary 是實驗性維護計劃，可提供對更新的早期存取。 它可讓客戶測試與適用於 MySQL 的新 Azure 資料庫版本的工作負載相容性，並提供新功能的意見反應。
與例行維護不同，Virtual Canary 不遵循 30 天的最短間隔或 7 天的通知期限。 此計劃可協助客戶主動驗證新功能，並為產品改善提供早期意見反應。 通常用於非生產環境的可高載層伺服器會自動在 Virtual Canary 計劃中註冊。
Virtual Canary 註冊
適用於 MySQL 的 Azure 資料庫可讓客戶彈性管理他們如何參與 Virtual Canary 計劃。 客戶可以根據需要選擇加入或退出該計劃，以配合他們的作業需求。
若要確認您的伺服器是否已在 Virtual Canary 計劃中註冊，請使用下列命令。 如果結果包含 "patchStrategy": "VirtualCanary"，表示伺服器已在計劃中註冊。
az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"
若要在 Virtual Canary 計劃中註冊伺服器，請執行下列命令：
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary
若要離開 Virtual Canary 程式並還原為標準維護原則，請使用下列命令：
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular
維護期間
您可以排定在一週的特定日期和當日的時間範圍內執行維護。 或者，您可以讓系統自動挑選一天和一個時間範圍。 無論哪種方式，系統都會在系統執行任何維護前七天警示您。 系統也會告訴您維護何時啟動，以及何時成功完成。
即將進行排程維護的通知分為以下幾類：
- 透過電子郵件傳送至特定地址。
- 透過電子郵件傳送給 Azure Resource Manager 角色。
- 在簡訊中傳送至行動裝置。
- 以通知的形式推送至 Azure 應用程式。
- 以語音訊息的形式傳遞。
當您指定維護排程的喜好設定時，您可以挑選一周中的一天和時間範圍。 如果您未指定喜好設定，系統會在伺服器區域時間的下午 11 點到上午 7 點之間挑選時間。 您可以為 Azure 訂用帳戶中的每個彈性伺服器定義不同的排程。
您可以隨時更新排程設定。 如果為您的彈性伺服器排定了維護計畫，而且您更新了排程偏好設定，則當前的部署仍將按原定計畫進行。 排程設定的變更會在下一次排程維護順利完成時生效。
您可以為 Azure 訂用帳戶中的每個彈性伺服器定義系統管理的排程或自訂排程：
- 透過自定義排程，您可以選擇星期幾和一小時的時間範圍，以指定伺服器的維護時段。
- 使用系統管理的排程，系統會在伺服器區域時間的下午 11 點到上午 7 點之間挑選任何一小時的時間範圍。
重要事項
自 2024 年 8 月 31 日起，適用於 MySQL 的 Azure 資料庫不再支援高載層實例的自定義維護時段。 這項變更有助於簡化維護程式，並確保最佳效能。 此外，我們的分析指出，在可高載層中使用自訂維護期間的使用者數量最少。
具有自訂維護期間的現有可高載層執行個體不會受到影響。 不過，用戶無法再修改自定義維護時段的這些設定。
對於需要自定義維護時段的客戶，建議升級至一般用途或業務關鍵層。
在罕見的情況下，系統可能會取消維護事件，或可能無法順利完成。 如果維護工作失敗，更新將會被取消，並恢復之前版本的執行檔。 在失敗的更新案例中，您可能仍會在維護期間重新啟動伺服器。
如果維護事件已取消或失敗，系統會傳送通知給您。 下一次嘗試執行維護會根據目前的設定進行排程。 您會提前五天收到有關下一次嘗試的通知。
近零停機維護 (預覽)
適用於 MySQL 的 Azure 資料庫 幾乎零停機維護 功能是高可用性伺服器開創性的開發。 這項功能的設計目的是要大幅減少維護停機時間。 這項功能對於需要高可用性並最大限度地減少資料庫中斷的企業而言至關重要。
精確的停機時間預期
- 停機時間持續時間：在大部分情況下，維護期間的停機時間從 10 到 30 秒不等。
- 其他考慮：故障轉移事件之後，會有大約30秒的固有 DNS 存留時間（TTL） 期間。 此期間不是由維護流程直接控制，而是 DNS 的標準行為之一。 因此，從客戶的觀點來看，維護期間發生的總停機時間可能是 40 到 60 秒。
條件和限制
若要達到這項功能所提供的最佳效能，請注意下列條件和限制：
- 所有數據表的主鍵：確保每個數據表都有主鍵很重要。 缺少主鍵可能會大幅增加複寫延遲，並影響停機時間。
- 維護期間低工作負載：維護期間應該與伺服器上的低工作負載時間一致，以將停機時間降到最低。 建議您使用 自定義維護時段 ，在離峰時段排程維護。
- 停機時間保證：雖然我們努力保持維護停機時間盡可能低，但我們並不保證在所有情況下都會少於 60 秒。 各種因素，例如高工作負載或特定伺服器組態，可能會增加停機時間。 在最壞的情況下，停機時間可能與獨立伺服器的情況類似。
維護排程
維護重新排程功能可讓您更大程度地掌控 MySQL 用 Azure 資料庫彈性伺服器上的維護活動時間。 在收到維護通知後，您可以將其重新安排到更方便的時間，無論是由系統管理還是自定義管理。
使用這項功能來避免在重要資料庫作業期間發生中斷。 由於我們會持續開發這項功能，歡迎您提供意見反應。
重新排程參數和通知
重新排程不限於固定的時段。 這取決於目前維護週期中最早和最新的允許時間。 週期通常會從區域維護時段的第一天到最後一天。 當您重新排程時，會根據標準通知原則收到通知來確認變更。
考量與限制
請注意有關此功能的下列幾點：
- 階層可用性：維護重新排程不適用於可高載計算層。 這項功能適用於生產環境中的伺服器，而Burstable層則是針對非生產環境用途所設計。
- 需求限制：如果相同區域中同時發生大量維護活動，您的重新排程維護可能會取消。
- 鎖定期間：為了維護服務的可靠性，在初始排程的維護時間前 15 分鐘會無法使用重新排程。
- 重新排程節流：如果相同區域中有太多伺服器排程在同一時間進行維護，則重新排程要求可能會失敗。 如果發生此失敗，您會收到錯誤通知，建議您選擇替代的時段。 成功重新排程的維護可能無法取消。
維護事件可以重新排程的次數沒有任何限制。 只要維護事件未進入 準備 狀態，您隨時都可以將它重新排程到另一次。
附註
建議您在預覽階段密切監視通知，以配合潛在的調整。
常見問題集
為什麼我的某些伺服器收到維護通知，而另一些伺服器則沒有收到維護通知？
維護開始時間會因區域而異。 不同區域中的伺服器可能會在不同的時間收到維護通知。
為什麼相同區域中的某些伺服器收到維護通知，而另一些伺服器則沒有收到維護通知？
最近可能會建立未收到通知的伺服器，而且系統判斷它們還不需要維護。
我可以取消排定的維護嗎？
不，不能取消排程維護。 不過，您可以使用維護重新排程功能來調整時間。 或者，您可以啟用高可用性功能，以將停機時間降到最低。 因為「適用於 MySQL 的 Azure 資料庫」是平臺即服務（PaaS）資料庫產品，因此執行及時維護有助於確保資料庫的安全性和可靠性。