共用方式為

適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中的排程維護

  • 發行項

適用於：適用於 MySQL 的 Azure 資料庫 - 彈性伺服器

適用於 MySQL 的 Azure 資料庫彈性伺服器會執行定期維護，讓您的受控資料庫保持安全、穩定的最新狀態。 在維護期間，伺服器會取得新的功能、更新和修補檔。

重要

在適用於 MySQL 的 Azure 資料庫彈性伺服器維護期間，請避免所有伺服器作業 (修改、設定變更、啟動/停止伺服器)。 參與這些活動可能會導致無法預期的結果，可能會影響伺服器效能和穩定性。 等到維護結束，再執行伺服器作業。

維修週期

例行維修

我們的標準維修週期排程頻率不低於每 30 天一次。 此期間可讓我們確保系統穩定性和效能，同時將服務中斷減到最少。

重大維修

在某些情況下，例如需要部署緊急安全性修正程式，或更新對於維修可用性和資料完整性至關重要的更新，可能會更頻繁地進行維修。 這些例外狀況是為了保護您的資料，並確保服務持續作業。

找出維修詳細資料

如需每個維修更新需要哪些特定詳細資料，請參閱我們的發行備註。 這些備註提供維修期間所套用之更新的完整資訊，讓您了解並為會影響環境的任何變更作準備。

注意

並非所有伺服器在排程更新期間都一定會進行維修，無論是例行還是重大維修。 Azure MySQL 小組會採用特定準則來判斷哪些伺服器需要維修。 此選擇性方法可確保既有效率又重要的維修，可針對每個伺服器環境的獨特需求量身打造，並將生產停機時間降到最低。

選取維護時段

您可以排定在一週的特定日期和當日的時間範圍內執行維護。 或者，您可以讓系統自動挑選一天和一個時段。 不論是哪一種方式，系統都會在執行任何維護的七天前向您發出警示。 系統也會讓您知道維護開始及成功完成的時間。

即將進行排程維護的通知分為以下幾類：

  • 已傳送電子郵件至特定地址
  • 傳送電子郵件給 Azure Resource Manager 角色
  • 發送簡訊 (SMS) 至行動裝置
  • 以通知的形式推送至 Azure 應用程式
  • 以語音訊息的形式傳遞

指定維護排程的喜好設定時，您可以挑選星期幾和時間範圍。 若未指定，系統將會依據您伺服器的區域時間挑選晚上 11 點和早上 7 點之間的時間。 您可以為 Azure 訂用帳戶中的每個彈性伺服器定義不同的排程。

您可以隨時更新排程設定。 如果彈性伺服器已有排程維護，而您更新了排程喜好設定，那麼目前的計畫會依照原訂排程繼續進行，而排程設定變更會在下次排程維護成功完成時生效。

您可以定義 Azure 訂用帳戶中每個彈性伺服器的系統代管排程或自訂排程。

  • 若使用自訂排程，您可以指定伺服器的維護時段，選擇星期幾和一小時的時段。
  • 若使用系統代管排程，系統會在伺服器所在區域時間的晚上 11 點到上午 7 點之間挑選任何一小時的時段。

重要

此前，系統管理的排程和自訂管理的排程之間有保持 7 天的部署差距。 但由於維護需求不斷增加，加上 維護重新排程功能 (公開預覽) 的引進，我們無法再保證這 7 天的差距。

在罕見情況下，系統可能會取消維護事件，或可能無法順利完成。 如果更新失敗，系統會還原更新，並還原舊版的二進位檔。 在這類失敗的更新案例中，伺服器可能仍會在維護時段重新啟動。 如果更新已取消或失敗，系統會分別建立有關維護事件已取消或失敗的通知給您。 下次嘗試執行維護的時間會根據您目前的排程設定進行排程，而且您會在執行的 5 天前收到通知。

近零停機維護 (公開預覽)

適用於 MySQL 的 Azure 資料庫彈性伺服器的「近零停機維護」功能是已啟用 HA (高可用性) 伺服器的突破性開發。 這項功能的設計目的是大幅減少維護停機時間，以確保在大部分情況下，維護停機時間預期在 40 到 60 秒之間。 這項功能對於需要高可用性並最大限度地減少資料庫中斷的企業而言至關重要。

精確的停機時間預期

  • 停機持續時間: 在大部分情況下，維護期間的停機時間從 10 到 30 秒不等。
  • 其他考量: 容錯移轉事件之後，會有大約 30 秒的固有 DNS 存留時間 (TTL) 期間。 此期間不是由維護流程直接控制，而是 DNS 的標準行為之一。 因此，從客戶的觀點來看，維護期間發生的總停機時間可能介於 40 到 60 秒之間。

限制和必要條件

若要達到這項功能所承諾的最佳效能，應注意某些條件和限制:

  • 所有資料表中的主索引鍵: 確保每個資料表都有主索引鍵非常重要。 缺少主索引鍵可能會大幅增加複寫延遲，進而影響停機時間。
  • 維護期間低工作負載: 維護期間應該與伺服器上的低工作負載時間一致，以確保停機時間維持在最低。 建議您使用 自訂維護時段 功能，在非尖峰時段排程維護。
  • 停機時間保證： 雖然我們努力讓維修停機時間儘可能降低，但我們不保證在所有情況下一律會少於 60 秒。 各種因素，例如高工作負載或特定伺服器組態，可能會導致更長的停機時間。 在最壞的情況下，停機時間可能與獨立伺服器的情況類似。

維護重新排程 (公開預覽)

重要

維護重新排程功能目前為預覽狀態。 它受限於限制和持續開發。 我們重視您的意見反應，以協助增強這項功能。 請注意，此功能不適用於使用高載 SKU 的伺服器。

維護重新排程 功能可讓您更充分掌控適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體的維護啟用時間。 在收到維護通知之後，您可以將其重新排程到更方便的時間，無論它是系統還是自訂管理。

重新排程參數和通知

重新排程不限於固定時段；這取決於目前維護週期中最早和最晚的允許時間。 重新排程之後，將會傳送通知以確認變更，並遵循標準通知原則。

考量與限制

使用這項功能時請注意下列事項:

  • 需求限制: 您重新排程的維護可能會因為相同區域中同時發生大量維護活動而遭到取消。
  • 鎖定期間: 為了維護服務的可靠性，在初始排程的維護時間前 15 分鐘會無法使用重新排程。

只要維護未進入「準備中」狀態，就可以無限次數地重新排程維護，您隨時可以將維護重新排程到其他時間。

注意

建議您在預覽階段密切監視通知，以配合潛在的調整。

使用這項功能來避免在重要資料庫作業期間發生中斷。 由於我們會持續開發這項功能，歡迎您提供意見反應。

下一步