監控 AlwaysOn 集群中的維護任務
我有一個在單個伺服器上具有多個 AG 的環境，它們遇到分裂情況，其中一些最終在一個節點上，而另一些最終在另一個節點上（可能是在故障轉移事件中）。當維護任務（重新索引、更新等基本範圍）在這些節點上執行時，它們只會在各自 AG 的主端上的 read_write 數據庫上有效地執行操作。這會導致作業失敗，因為數據庫在輔助節點上是只讀的。因此，在分裂 AG 的情況下，兩個節點都會在作業歷史記錄中顯示維護失敗。
不用說，很難監控這些集群。我提出了兩種可能的管理解決方案。我們要麼根據數據庫的可更新性屬性使用 DBCC 命令為各個數據庫編寫維護任務腳本，要麼僅將自己限制為每台伺服器一個 AG。他們不喜歡這兩種解決方案。有誰知道我可以保留內置 SQL Server 維護任務並讓它們僅針對主數據庫的方法？
SQL Server 維護計劃沒有內置功能來檢測特定數據庫的 AG 副本狀態並採取相應措施。為此，您必須實現自定義功能。
根據您實施維護任務的方式，有幾個選項可供選擇。
選項1：
如果您使用 SQL 維護計劃，則為每個可用性組創建一組維護計劃並僅針對該組中的數據庫。刪除這些計劃的計劃，然後創建一個按您想要的計劃執行的 SQL 代理作業。讓該代理作業檢查sys.dm_hadr_availability_replica_states以確認相關 AG 處於主要狀態，如果是，則執行相應的代理作業以執行維護計劃任務。
選項#2：
如果您使用帶有 T-SQL 腳本的 SQL 代理作業來執行維護任務，請在腳本中添加一些邏輯以在執行之前檢查sys.dm_hadr_database_replica_states以驗證所討論的數據庫確實是主數據庫。
選項#3：
重新設計您的維護流程，以利用Ola Hallengren出色的維護解決方案。這具有處理已內置可用性組的邏輯，因此可以節省您自己設計、測試和部署解決方案的時間。您只需部署一組相同的代理作業即可在每個副本上執行儲存過程。它們都會執行，但只有您想要執行任何工作的那些才會執行。
筆記：
- Ola 解決方案中的某些任務始終在所有副本上執行，例如完整性檢查和伺服器級維護（日誌循環等）。這些應該在所有副本上執行（是的，甚至是完整性檢查），所以你不應該擔心這一點。
- Ola 的解決方案在備份之前使用sys.fn_hadr_backup_is_preferred_replica檢查首選備份副本，因此請確保在 AG 上正確設置了備份首選項。
- 通常，大多數 DBA 不推薦維護計劃，因為它們通常會帶來不靈活。通常首選基於 T-SQL 或 PowerShell 的解決方案，因為它們更加健壯。
- 選項 #2 和 #3 本質上是相同的，但選項 #3 意味著其他人已經為您完成了艱苦的工作。此外，此解決方案的廣泛使用意味著如果您遇到問題，SQL 社區中會有很多幫助和建議。
這些選項中的任何一個都應該以相同的作業部署在所有副本上並同時執行的方式進行部署。唯一的區別是某些任務僅在主副本上執行，而其他任務只是執行作業並由於副本狀態而安靜地退出，不執行任何工作。
您的管理團隊可能不喜歡重構目前維護流程的想法，但現實情況是，如果他們想要自動化處理故障轉移，他們必須這樣做，否則，維護任務必須在故障轉移後手動管理。