Azure SQL 受控執行個體 中的維護期間
適用於:Azure SQL 受控執行個體
維護時段功能可讓您為 Azure SQL 受控執行個體 資源設定維護排程,讓工作負載產生可預測的影響性維護事件,並降低干擾性。
注意
維護時段功能只會防止來自升級或排程維護的規劃影響。 它不會保護所有故障轉移原因;可能導致維護期間外部短暫連線中斷的例外狀況包括硬體故障和其他重新設定。
事先通知可讓客戶將通知設定為在任何計劃性事件前最多 24 小時傳送。
概觀
Azure 會定期執行 SQL 受控實例資源的計劃性維護 。 在維護事件期間,SQL 受控實例已完全可用,但可能會受限於 SQL 受控實例的可用性服務等級協定 (SLA) 內的簡短重新設定。
維護期間適用於無法復原實例重新設定且無法吸收計劃性維護事件所造成的短暫連線中斷的生產工作負載。 藉由選擇您偏好的維護時段,您可以將計劃性維護的影響降到最低,方法是將它排程到尖峰上班時間之外。 復原工作負載和非生產工作負載可以依賴 Azure SQL 的預設維護原則。
維護期間是免費的,可以在建立或現有資源時設定。 您可以使用 Azure 入口網站、PowerShell、CLI 或 Azure API 來設定。
重要
設定維護時段是一項長時間執行的非同步作業,類似於變更 Azure SQL 資源的服務層級。 資源可在作業期間使用,但在作業結束時所發生的短暫重新設定除外,即使在中斷長時間執行的交易時,通常也會持續最多 8 秒的時間。 若要將重新設定的影響降到最低,您應該在尖峰時間以外的時間執行作業。
使用維護時段獲得更多可預測性
根據預設,Azure SQL 維護原則會在當地每天上午 8 點到下午 5 點期間封鎖大部分具影響力的更新,以避免在一般尖峰上班時間期間發生任何中斷。 當地時間取決於裝載資源的 Azure 區域位置,而且可能會根據當地時區定義觀察日光節約時間。
在維護期間,資料庫仍可供使用,但某些更新可能需要故障轉移。 系統預設維護時段(下午 5 點到上午 8 點)將大部分的活動限制在這次,但緊急更新可能會發生在其外部。 若要確保所有更新只會在維護期間發生,請選取非預設選項。
您可以選擇兩個非預設維護時段位置,將維護更新的時間調整為適合 Azure SQL 資源的時間:
- 工作日時段:當地時間下午 10:00 到上午 6:00,週一 - 週四
- 週末時段:當地時間下午 10:00 到上午 6:00,週五 - 週日
列出的維護時段天數表示每八小時維護時段的開始日期。 例如,「當地時間下午 10:00 到上午 6:00,週一 - 週四」表示維護時段從當地時間每天 (週一到週四) 下午 10:00 開始,並且在當地時間隔日 (週二到週五) 上午 6:00 完成。
一旦進行維護期間選取,且服務設定完成,計劃性維護只會發生在您選擇的時段內。 雖然維護事件通常會在單一視窗中完成,但其中一些事件可能會跨越兩個以上的相鄰視窗。
重要
Azure SQL 受控執行個體 遵循安全部署做法,保證 Azure 配對區域不會同時部署到其中。 不過,無法預測哪些區域會先升級,因此不保證部署順序。 有時候,您的主要實例會先升級,有時會是次要實例。
進階通知
維護通知可以設定為警示您即將針對 Azure SQL 受控執行個體的計劃性維護事件。 警示會提前 24 小時抵達,在維護期間開始前,以及在維護結束時。 如需詳細資訊,請參閱預先通知。
功能可用性
支援的訂用帳戶類型
設定和使用維護期間適用於下列供應項目類型:隨用隨付、雲端解決方案提供者(CSP)、Microsoft Enterprise 合約 或 Microsoft 客戶合約。
僅限開發/測試使用量的供應專案不符合資格(例如隨用隨付開發/測試或企業開發/測試作為範例)。
注意
Azure 供應項目是您擁有之 Azure 訂用帳戶的「類型」。 例如,採用隨用隨付費率的訂用帳戶、Azure in Open 和 Visual Studio Enterprise 皆為 Azure 供應項目。 每個供應項目或方案各有不同的條款和權益。 您的供應項目或方案會顯示在訂用帳戶的概觀上。 如需將您的訂用帳戶切換至不同供應項目的詳細資訊,請參閱將 Azure 訂用帳戶變更為其他供應項目。
支援的服務等級目標
除了 Azure SQL 受控執行個體 集區以外,除了選擇預設以外的維護時段,所有 SLO 都可以使用。
維護時段 Azure SQL 受控執行個體 區域支援
在下列區域中,目前有下列區域提供 Azure SQL 受控執行個體 以外的維護時段:
- 澳大利亞中部 1
- 澳大利亞中部 2
- 澳大利亞東部
- 澳大利亞東南部
- 巴西南部
- 巴西東南部
- 加拿大中部
- 加拿大東部
- 印度中部
- 美國中部
- 中國東部 2
- 中國北部 2
- 美國東部
- 美國東部 2
- 東亞
- 法國中部
- 法國南部
- 德國中西部
- 德國北部
- 日本東部
- 日本西部
- 南韓中部
- 南韓南部
- 美國中北部
- 北歐
- 挪威東部
- 挪威西部
- 南非北部
- 南非西部
- 美國中南部
- 印度南部
- 東南亞
- 瑞士北部
- 瑞士西部
- 阿拉伯聯合大公國中部
- 阿拉伯聯合大公國北部
- 英國南部
- 英國西部
- US Gov 亞利桑那州
- US Gov 德克薩斯州
- US Gov 維吉尼亞州
- 美國中西部
- 西歐
- 印度西部
- 美國西部
- 美國西部 2
- 美國西部 3
閘道維護
在 Azure SQL 受控執行個體 中,網關節點裝載於虛擬叢集內,且與 SQL 受控實例具有相同的維護期間。
重要
建議使用 重新導向連線原則 ,將維護事件期間的中斷次數降到最低,請參閱 連線類型。
Azure SQL 受控執行個體的考量
Azure SQL 受控執行個體 包含一組專用隔離虛擬機上裝載的服務元件,這些虛擬機會在客戶的虛擬網路子網內執行。 這些虛擬機會組織成群組,形成 可裝載多個受控實例的虛擬叢集 。 由於針對相同子網中的實例所設定的維護期間可能會影響虛擬叢集和虛擬叢集管理作業內的虛擬機群組數目,因此在設定維護期間之前,需要考慮一些事項。
維護時段設定是一項長時間執行的作業
裝載在相同虛擬機群組中的所有實例都會共用相同的維護期間。 根據預設,所有受控實例都會裝載在具有默認維護時段的群組中。 如果您在建立實例時指定另一個維護期間,或建立實例之後,實例會放入具有對應維護時段的個別機器群組中。 如果叢集中沒有這類群組,則會建立新的群組以容納實例的新組態。 如果您將虛擬叢集中的其他實例設定為使用相同的維護期間,這些實例也會新增至群組,這表示可能需要調整群組的大小。 將實例新增至新的計算機群組,以及調整現有計算機群組的大小,可能會增加作業的持續時間以設定維護期間。
設定受控實例維護期間的預期持續時間,可以使用實例管理作業的估計持續時間來計算。
重要
當您設定維護期間時,作業的最後一個步驟需要重新設定通常持續最多 8 秒的實例,即使它中斷長時間執行的交易也一樣。 若要將影響降到最低,請在尖峰上班時間以外設定維護期間。
IP 位址空間需求
子網中的每個新虛擬機群組都需要根據 虛擬叢集IP位址配置的額外IP位址。 變更現有受控實例的維護時段也需要 暫時性的額外IP容量,類似於調整個別服務層級的虛擬核心數目時。
IP 位址變更
設定或變更維護期間,會將實例的IP位址變更為子網IP位址範圍內的不同IP位址。
重要
確定網路安全組 (NSG) 和防火牆規則不會在IP位址變更後封鎖數據流量。
虛擬叢集管理作業的序列化
會影響虛擬叢集的作業,例如服務升級或調整虛擬叢集的大小(例如新增或移除未使用的計算節點),都會串行化。 因此,在上一個作業完成之前,新的虛擬叢集作業無法啟動。 如果維護期間在進行中的維護作業完成之前關閉,則會保留進行中的維護作業,直到下一個維護期間為止。 在此期間提交的其他管理作業也會保留,並在原始持續維護作業完成之後,於下一個維護期間或之後繼續執行。 維護作業在叢集內每個虛擬機群組花費的時間超過單一維護時段並不常見,但可能會發生非常複雜的維護作業。
虛擬叢集管理作業的串行化也是套用至默認維護原則的一般行為。 當您設定維護期間排程時,兩個相鄰視窗之間的期間可能會很長幾天。 雖然罕見,如果維護作業跨越兩個視窗,則新提交的作業可以保留數天,可能會封鎖需要其他計算節點的作業,例如建立新的或調整現有實例的大小。
擷取維護事件清單
Azure Resource Graph 是一項 Azure 服務,其旨在延伸 Azure 資源管理。 Azure Resource Graph Explorer 會透過大規模查詢一組指定訂用帳戶的能力,提供有效率且高效能的資源探索,讓您可以有效地治理環境。
您可以使用 Azure Resource Graph Explorer 來查詢維護事件。 如需如何執行這些查詢的簡介,請參閱快速入門:使用 Azure Resource Graph Explorer 執行您的第一個 Resource Graph 查詢。
若要檢查訂用帳戶中所有 SQL 受控實例的維護事件,請在 Azure Resource Graph 總管中使用下列範例查詢:
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
如需範例查詢的完整參考,以及如何跨 PowerShell 或 Azure CLI 等工具加以使用,請瀏覽 Azure Resource Graph 的 Azure 服務健康情況範例查詢。
相關內容
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應