高可用性和災害復原檢查清單 - Azure SQL 受控執行個體
適用於：
Azure SQL 受控執行個體
Azure SQL 受控執行個體服務會自動確保所有資料庫都在線上、狀況良好，並且持續努力達成已發佈的 SLA。
本指南為您可以主動採取的步驟提供了詳細評論，包含最大化可用性、確保復原，以及為 Azure 中斷最好準備等步驟。 本指南適用於 Azure SQL 受控執行個體的所有服務層級。
可用性檢查清單
以下是以最大化可用性的建議設定：
- 在應用程式中加入重試邏輯以處理暫時性錯誤。
- 使用維護時段，讓會造成影響的維護事件容易預測，並降低干擾性。
- 手動觸發容錯移轉以測試應用程式錯誤復原能力，來查看復原性的運作情形。
高可用性檢查清單
以下是達到高可用性的建議組態：
- 啟用可供 SQL 受控執行個體使用的區域備援，以確保區域失敗時的復原能力。
災害復原檢查清單
雖然 Azure SQL 受控執行個體會自動維護可用性，但當中斷的影響橫跨整個區域時，即便具有高可用性（區域備援）的執行個體也可能無法保證復原性。 區域性 Azure SQL 受控執行個體中斷時，可能需要由您起始災害復原。
若要為災害復原做好最佳準備，請遵循下列建議：
- 啟用執行個體容錯移轉群組。
- 在應用程式連接字串中使用讀寫和唯讀接聽程式端點，讓應用程式自動連線到主要執行個體。
- 將容錯移轉原則設定為客戶管理。
- 在建立異地次要執行個體時，請確定其具與主要執行個體相同的服務層級、硬體世代與計算大小。
- 擴大時，先擴大異地次要資料庫，再擴大主要資料庫。
- 縮小時，則反轉順序：先縮小主要資料庫，再縮小次要資料庫。
- 災害復原在本質上旨在活動主要和次要地區之間的資料非同步複寫。 若比起較高的提交延遲，要讓資料可用性的優先順序更高，請考慮在提交交易之後立即呼叫 sp_wait_for_database_copy_sync 預存程序。 呼叫
sp_wait_for_database_copy_sync會封鎖呼叫執行緒，直到最後認可的交易已傳輸和強行寫入次要資料庫交易記錄為止。 - 使用主資料庫上 sys.dm_geo_replication_link_status 動態管理檢視 (DMV) 的
replication_lag_sec資料行，來監視復原點目標 (RPO) 的延遲。 其中會顯示主要資料庫上認可交易之間的延遲 (以秒為單位)，並將其強行寫入次要資料庫上的交易記錄。 例如，如果某個時間點的延隔時間是一秒，如果主要資料庫在這段時間受到中斷的影響並起始異地容錯移轉，則在上一秒認可的交易將會遺失。 - 如果無法啟用容錯移轉群組，請考慮將備份儲存體備援選項設定為異地備援備份儲存體，以使用異地還原功能。
- 此選項不適用於沒有區域配對的區域。
- 經常規劃和執行災害復原演練，可讓您在實際發生中斷時較不會手忙腳亂。
準備針對中斷的次要複本
若要使用容錯移轉群組或異地還原，成功復原到另一個資料區域，您必須在另一個區域中準備次要 Azure SQL 受控執行個體。 必要時，這個次要執行個體可能會成為新的主要執行個體。 您也應該有書面資料，清楚記載復原步驟並實際進行測試，以確保復原能夠順暢。 這些準備步驟包括︰
- 若要進行異地復原，請先找出位在另一個區域，且要成為新主要執行個體的執行個體。 一般而言，這就是在主要執行個體所在區域的配對區域中的執行個體。 使用與主要區域配對區域的執行個體可以消除異地還原作業期間的額外流量成本。
- 決定要如何將使用者重新導向到新的主要伺服器。 重新導向使用者可以透過手動變更應用程式連接字串或 DNS 項目來完成。 如果您已啟用容錯移轉群組，並在應用程式連接字串中使用了讀寫及唯讀接聽程式，則不需要採取進一步的動作，因為容錯移轉後，系統會自動將連線導向到新的主要伺服器。
- 識別並選擇性地定義 NSG 與路由表組態，使用者需要其來存取新主要伺服器的新主要資料庫。
- 找出 (或是建立) 登入，新主要伺服器的
master資料庫中必須有這些登入，且須確保這些登入在master資料庫中有適當的權限 (如果有的話)。 - 記錄目前主要執行個體的稽核組態，並在次要執行個體設定相同組態。
相關內容
若要深入了解，請檢閱：