標籤：圖形化 secondary 也有 檢查 detail windows 對象 備份 測試
本文屬於管理SQL Server AlwaysOn 系列文章
前言：
前面系列已經介紹了SQL Server AlwaysOn的知識點、安裝示範及注意事項等。但是這並不是終點，更多的反而是起點。就像不能生了孩子就不管，你還得養（管理）。作為DBA，更多的工作內容恰恰就是管理AlwaysOn。所以這裡單獨列出一個系列介紹SQL Server AlwaysOn的管理。本系列沿用從0開始部署基礎的AlwaysOn 的環境。在這個系列中，準備講述以下內容：
- 管理SQL Server AlwaysOn（1）——基礎維護
- 管理SQL Server AlwaysOn（2）——添加、移除次要複本
- 管理SQL Server AlwaysOn（3）——可用性群組備份
- 管理SQL Server AlwaysOn（4）——常見異常
- 管理SQL Server AlwaysOn（5）——常規監控（1）——常規監控
- 管理SQL Server AlwaysOn（5）——常規監控（2）——擴充事件監控
- 管理SQL Server AlwaysOn（6）——警告
- 管理SQL Server AlwaysOn（7）——待補充
註：由於工作所需，可能不會按順序更新。
基礎維護：
針對基礎維護，本文大概介紹以下內容：
- 群集維護，包括補丁升級。
- 管理可用性群組，包括如何進行同步/非同步節點的容錯移轉。
- 添加多個接聽程式
- 其他管理內容
下面我門開始進行介紹和示範，如果讀者未有實操環境，可以參考開篇中提到的文章，先自行搭建，如果已有環境，建議先進行虛擬機器的備份，因為有些操作具有大殺傷性。
群集管理：
本系列的主題是SQL Server AlwaysOn，而僅僅因為AlwaysOn需要建立在Windows Server Failover Cluster（WSFC，簡稱Windows群集）上，所以我們有必要把底層環境稍微介紹一下，但是不會做深入介紹，畢竟每個知識點學深了，都不是小事。首先我們必須清楚，群集安裝完畢並不等於工作結束，從安裝完畢開始，我們的管理和維護工作才真正開始。這一部分會介紹：
節點間移動執行個體：
在日常營運當中，除了防止意外斷電之外，其中一個部署高可用技術的好處就是可以明顯降低維護過程中導致的停機時間。特別是對作業系統或者SQL Server進行打補丁操作。如果你的環境是雙節點群集（假設為A，B，A為主節點/活動節點。B為被動節點）， 那麼在打補丁等可能引發重啟等操作時，就要進行節點移動。步驟如下：
- 對被動節點B進行補丁升級。（A主B被）
- 第一步成功後，把主節點A的執行個體容錯移轉（Failover）到被動節點B。此時原主動節點A和原被動節點B的角色就對調了。（A被B主）
- 對原主動節點A，現被動節點進行補丁升級。成功之後，操作已經算完成了。（A被B主）
然後根據具體需要再決定是否要把活動執行個體（現在的B）切換回去A節點。這個沒有強制要求，但是需要考慮實際情況。比如執行個體的可用性是第一優先順序並遠大於其他一切要求，那麼可能不適合再Failover回去，因為這個操作會引發短暫的服務不可用。又或者因為B節點是為了提供效能而配置的高水平伺服器，那麼通過這種打補丁或者Failover操作把服務移到更新，更強的節點之後，就沒必要Failover回去原有節點，當然，WSFC建議使用等配的軟硬體設定，所以在此之後，最後把A也提升到同等配置。為了完成上面的步驟，可以用兩種方法，一種是圖形操作，另外一種是PowerShell命令。
圖形操作：
首先登入到節點1，開啟容錯移轉叢集管理員，對Windows的Cluster角色名稱進行右鍵→【移動】→【選擇節點】：
此時會顯示【移動叢集角色】對話方塊：
：
在中可以選擇想移動的節點，由於目前是雙節點，所以實際上是沒有其他選擇，點擊確定之後，節點開始移動，移動完畢之後會看到：
PowerShell操作：
在許可權足夠的前提下，使用Move-ClusterGroup cmdlet可以實現角色的容錯移轉。比如下面命令可以把Node1的角色Failover到Node2：
Move-ClusterGroup -Name "WSFC叢集角色名" -Node 目標節點名
注意WSFC叢集角色名是有雙引號的。示範環境下的樣子是所示，注意我的環境現在是Node1為所有者，我希望轉到Node2，所以在PowerShell裡面我需要寫上“目標節點名”：
執行後，不用重新整理都可以看到當前的群集所有者已經換成了Node2：
再次囉嗦一下，本文是以基礎維護為目標，並關注在SQL Server AlwaysOn上，所以對WSFC的真正專業的維護不在討論和示範範疇。
滾動補丁升級：
上面示範的是雙節點群集，在大型生產環境中，超過2節點的群集很普遍，此時如果要對SQL Server進行升級，就需要考慮滾動補丁更新。我們假設現在SQL Server運行在不同的大版本或者小版本上，可能會導致資料損毀，所以需要通過打補丁進行修複。下面是操作步驟：
- 列出角色中的所有節點的可能擁有者。
- 選擇其中50%個節點，然後移除掉這些可能擁有者。，因為這裡只有兩節點，所以就只能勾選掉其中一個，比如Node1（因為當前活動節點在Node2，所以不能勾選掉Node2）。同樣可以用PowerShell命令實現：執行之後可以看到結果是一樣的
Get-ClusterResource "AlwaysOn角色名稱（本例中為SQLAG）" | Set-ClusterOwnerNode -Owners 保留的節點（本例中為Node2保留，即Node1去掉）
PowerShell執行示範：
- 當50%的可能擁有者節點移除後，就可以對勾選掉的節點進行補丁升級。在校正這些節點已經成功之後，把他們再次加回去。
- 把角色的節點移到其中一個已經升級成功的節點上。重複上面的操作，從可能的擁有者中移除未升級的節點→升級這些節點→驗證→加回角色的可能的擁有者列表中。
管理可用性群組：
對於AlwaysOn可用性群組，當完成配置之後，也要開始進行管理操作。包括可用性群組的容錯移轉、監控和在特殊情況下添加額外的接聽程式。下面將逐個討論：
容錯移轉：
當次要複本被配置為同步提交模式（synchronous commit mode）並設定了自動容錯移轉之後，當主副本遇到滿足容錯移轉條件時，可用性群組就會自動移到冗餘副本上。在某些情況下，需要手動容錯移轉。常見情況有：DR測試、計劃性維護操作等。
同步容錯移轉：
如果需要容錯移轉一個同步提交模式下的副本，可以在SSMS中，按方式在主副本上執行：
注意下面這個圖，如果你是在次要複本中開啟的容錯移轉介面，是沒有這一步的
然後點擊下一步和完成。如無報錯，則可用性群組轉移成功。但是這並不代表完事了，經常容易忘記的事情就是：檢查新主副本上的作業、帳號、程式是否正確配置並正常運行，這一點很重要，因為本人過去的環境中，未對次要複本配置記錄備份，而前面章節介紹過，AlwaysOn必須使用完整復原模式，在這種模式下，生產環境的資料庫記錄檔很可能會異常暴增導致磁碟空間不足從而停止服務。在以前一開始使用AlwaysOn的時候就遇到過這種情況，也有些情況是帳號配置問題、配套依賴程式未同步等因素導致轉移成功但系統無法正常運行。所以要有足夠的檢查！同樣我們可以使用T-SQL來執行，比如我們現在需要從Node2切到Node1注意：在次要複本中執行下面命令：
ALTER AVAILABILITY GROUP 可用性群組名 FAILOVER ; GO
執行完之後重新整理一下就可以看到副本從“（輔助）”變成“（主要）”
非同步容錯移轉：
當可用性群組是非同步提交模式時，從技術上來說，可以像同步提交模式一樣進行Failover操作，但是你需要“強制”進行Failover，同時必須接受可能的資料丟失風險。可以使用下面命令進行Failover：注意需要在次要複本上執行：
--Run in the secondary replicaALTER AVAILABILITY GROUP SQLAG FORCE_FAILOVER_ALLOW_DATA_LOSS ;
除了在次要複本上執行之外，為了運行成功，你的群集還必須有仲裁，否則，需要強制把群集先聯機，才能強制AlwaysOn可用性群組聯機。為了儘可能避免資料丟失，可以 在可能的條件下進行計劃性Failover，下面是具體的操作步驟：
- 禁用各種登入帳號，但要確保進行操作的帳號不被禁用。
- 修改副本模式為同步提交模式。
- Failover
- 把提交模式改回非同步提交模式。
- 啟用第一步中禁用的帳號。
同步非包含對象：
不管使用哪種Failover模式，在執行個體層級都有一些對象是不包含在可用性群組中，所以需要進行同步。最直接的方式是使用SSIS包周期性同步執行個體間的對象。下面是一些需要同步的內容：
- Logins
- Credentials（認證）
- SQL Server Agent Jobs
- 自訂錯誤資訊
- Linked Servers
- 伺服器層級的事件警告
- Master庫中的預存程序
- 伺服器層級的觸發器
- 密鑰相關內容
添加多個接聽程式：
常規情況下，每個可用性群組只有一個單獨的可用性群組接聽程式（Listener），但是在某些極端情況下可能會對相同的可用性群組建立多個接聽程式。比如一些曆史遺留問題。此時可能需要建立一個額外的接聽程式用於寫入程式碼。但是，通過圖形化介面（SSMS）、T-SQL甚至PowerShell都不能建立第二個接聽程式，必須使用Failover Cluster Manager來實現。我們在我們的“SQLAG”角色內建立一個用戶端存取點（Client Access Point）資源。按下面步驟：
添加一個新的用戶端訪問點名，並輸入新的IP地址：
可以看到加了之後SQLAG角色的狀態是“部分運行中”，並且看到下面的新加用戶端訪問點是“離線”狀態：
此時我們右鍵新的用戶端訪問點並選擇屬性：
在【依賴關係】中，選擇【OR】，並添加原有的接聽程式名（本例是192.168.1.123）：
然後右鍵“AGListener2”，選擇聯機即可。一旦配置完成之後，用戶端可以使用任意一個接聽程式名進行訪問：
其他管理事項：
除了前面提到的之外，還有一些其他事項會把資料庫變成不可用，其中最明顯的就是不能把資料庫變成single-user或者read-only模式。因為這個會導致應用程式的安全狀態改變。這也是為什麼在Failover一節中，需要禁用登入帳號的原因。而且如果你必須變更資料庫的單一使用者模式，那麼首先需要移除可用性群組。可以使用下面命令從可用性群組中移除：
--次要複本上執行ALTER DATABASE TestAG SET HADR OFF ;
執行完畢後，次要複本從“已同步”變成了“正在還原”
這個時候又有可能需要把資料庫恢複回去，這時候可以執行下面語句：
--注意SET後面，HADR意味著HA和DR，從名字可以折射出AlwaysOn是包含了HA和DRALTER DATABASE TESTAG SET HADR RESUME;GO
另外一個重要的注意事項是資料庫及其記錄檔的部署。這些檔案必須存在每個副本中相同的路徑下。
總結：
關於SQL Server AlwaysOn的基礎基礎維護就先到這裡，如有後續補充會儘可能顯式添加進來或者必要時候另起一文。下一節介紹：管理SQL Server AlwaysOn（2）——添加、移除次要複本
管理SQL Server AlwaysOn（1）——基礎維護
