SQL Server 2016 Failover Cluster+ ALwaysOn(三)

SQL Server 2016 Failover Cluster+ ALwaysOn(三)
咱們前面兩篇文章介紹了SQL Server 2016 Failover Cluster的配置，同時又介紹配置新增AlwaysOn節點的先前條件，今天咱們主要介紹Always的詳細配置。咱們前面已經提到了，若是要實現SQL Server 2016 Failover Cluster+ ALwaysOn，SQL Server Failover Cluster兩個節點或者多個節點安裝一個SQL 實例，而後ALwaysOn也須要安裝一個單獨的實例，雖然AlwaysOn節點必需要加入Faillover Cluster中，可是要建立AlwaysOn必需要它和以前的SQL羣集實例之間建立AlwaysOn可用性組關係。另外AlwaysOn功能的開啓是在實例級設置的，這裏一共有2個SQL實例，因此就須要對這2個SQL實例分別進行設置。對於SQL羣集實例，在其任一全部者節點上使用SQL Server configuration manager設置一次就能夠了（重啓SQL服務後生效）。
咱們仍是繼續回顧上面的架構圖

接下來咱們配置ALwaysOn High Availability，咱們發現提示錯誤，可是有引導咱們如何配置

咱們經過SSMS右擊--AlwayOn High Avaliablity 會有一個提示，意思是必須爲服務器實例啓用AlwaysOn功能，以後才能在此實例上建立可用性組，若要啓用AlowaysOn，請打開SQL Server配置管理器，右鍵單擊SQL Server實例名稱，選擇屬性，而後使用SQL Server屬性對話框的AlwaysOn高可用性選項卡，咱們連接集羣地址，點擊ALways High Availability,提示咱們開啓的方法了
注意：咱們使用SSMS鏈接到SQL Server後，在服務器屬性對話框中,單擊通常頁面。 的HADR啓用屬性
顯示下列值之一:真正的若是啓用了老是在可用性組織；假,若是老是在可用性組是禁用的。

因此咱們要開啓功能

SQL Server服務---屬性--右擊

咱們將SQL Server服務的登陸帳戶換成域帳戶

咱們勾選啓用AlwayOn可用性組

應用--確認後，須要重啓數據庫服務

正在重啓服務

第二臺服務器的AlwaysOn當節點切換到節點2的時候，發先是自動勾選的；因此不用勾選；另外當角色不在操做的節點的時候，咱們就會發現LWAYSON高可用沒法操做；屬於正常現
象；咱們能夠經過系統提示的信息就會知道

咱們再次查看角色的狀態：如下狀態屬於正常現象，緣由是因爲啓用了ALwaysOn高可用

這種狀況下能夠選擇在節點上3安裝一個SQL命名實例，而後在它和以前的SQL羣集實例之間建立AlwaysOn可用性組關係。
另外AlwaysOn功能的開啓是在實例級設置的，這裏你一共有2個SQL實例，因此就須要對這2個SQL實例分別進行設置。對於SQL羣集實例，在其任一全部者節點上使用SQL Server
configuration manager設置一次就能夠了（重啓SQL服務後生效）。
咱們一樣先將節點三的ALwaysOn高可用×××打開

咱們用SSMS連接實例

咱們都知道高可用性是基於DB的，因此咱們須要建立數據庫：HAGourpDB1

同時建立一張表，perinfo

咱們插入數據

咱們開始在集羣實例下建立高可用性組

勾選數據庫層運行狀態檢測，定義高可用性組的名稱：HA-GP1

提示須要首先完整備份

因此咱們先備份一下

完整備份及備份類型

備份完成

咱們一樣備份Log

咱們須要將備份的數據庫和log在三節點還原一次

恢復狀態：RESTORE WITH NORECOVERY

恢復完成

數據庫狀態未還原模式

恢復事務log

一樣選擇恢復狀態

恢復完成

咱們繼續建立高可用性組，知足條件繼續下一步

咱們增長副本

不管是主副本或者輔助副本都選擇同步提交模式，輔助副本的Readable Secondary選擇爲Yes。只是爲了後面的只讀輔助數據庫準備。

AlwaysOn和鏡像同樣都採用Endpoint（端點）來進行數據傳輸。AlwaysOn使用端點是爲了和輔助副本進行日誌傳輸和心跳線的通訊

備份優先級勾選Prefer Secondary。意思是有限考慮輔助副本上作數據備份。只有在沒有輔助副本的狀況下才使用主副本。把輔助副本的優先級別調爲100，而主副本50。

咱們監聽端口稍後建立

確認便可---yes

這個地方是選擇初始化數據庫的方式。若是你選擇Full，你須要提供一個共享地址，AlwaysOn本身自動備份數據庫而後還原到目標的輔助副本上。這裏咱們選擇Join only，因此
咱們須要事先把數據庫備份並還原到目標的輔助數據庫上----Join only

開始下一步後，咱們查看狀態

建立完成


咱們展開數據庫高可用性組

咱們查看角色會多出一個高可用性組角色

咱們接着建立一個監聽
AlwaysOn建立後，客戶端就須要進行鏈接，爲了讓應用程序可以透明地鏈接到主副本而不受故障故障轉移的影響，咱們須要建立一個偵聽器，偵聽器就是一個虛擬的網絡名稱，能夠經過這個虛擬網絡名稱訪問可用性組，而不用關心鏈接的是哪個節點，它會自動將請求轉發到主節點，當主節點發生故障後，輔助節點會變爲主節點，偵聽器也會自動去偵聽主節點。
一個偵聽器包括虛擬IP地址、虛擬網絡名稱、端口號三個元素，一旦建立成功，虛擬網絡名稱會註冊到DNS中，同時爲可用性組資源添加IP地址資源和網絡名稱資源。用戶就可使用此名稱來鏈接到可用性組中。與故障轉移羣集不一樣，除了使用虛擬網絡名稱以外，主副本的真實實例名還能夠被用來鏈接。
SQL Server2012早期版本的SQL Server只有在實例啓動的時候地會嘗試綁定IP和端口，可是SQL Server2012卻容許在副本實例處於運行情況的時候隨時綁定新的IP地址、網絡名稱和端口號。所以能夠爲隨時爲爲可用性組添加偵聽器，並且這個操做會當即生效。當添加了偵聽器以後，在SQL Server的錯誤日誌中能夠看到相似：在虛擬網絡名稱上中止和啓動偵聽器的消息。
要注意的是，SQLBrowser服務是不支持Listener的。這是由於應用程序在使用Listener的虛擬網絡名鏈接SQLServer時，是以一個默認實例的形式進行訪問的（只有主機名，沒有實例名），所以客戶端根本就不會去嘗試使用SQLBrowser服務。

定義監聽名稱及IP
名稱：HA-LST;
IP地址：192.168.5.48;
Port爲1433

定義完成

咱們在查看角色，就會發現有對應的管理地址了

定義完成後，咱們能夠查看高可用行組的顯示面板

咱們能夠經過顯示面板查看高可用性組的狀態

接下來咱們切換一下；切換前咱們須要注意一個問題：切換的時候不能在集羣管理器裏面切換，須要在高可用性組下切換，否則會有問題，就算切換成功了，有些數據也會出現問題
咱們首先在集羣管理器裏面查看節點全部者

另外咱們鏈接到羣集節點後，發現高可用性組下的可用性副本的節點屬於輔助節點；

接下來咱們準備開始切換，咱們使用SSMS鏈接到第三個節點實例
查看當前可用性組下在第三個節點處於輔助副本狀態

咱們開始切換

選擇主副本

確認信息

轉移完成

咱們再查看AO1第三節點的AG狀態就成了主副本了

咱們再從主切換到備

選擇新的主副本

連接副本

開始鏈接

連接成功

確認轉移信息

轉移完成

咱們從SQLCLUSTER上插入一條數據

而後從AO1上查看數據

咱們從AO1上插入數據提示，數據庫爲只讀，因此沒法插入數據

緣由是因爲當前節點屬於第二節點，若是可讀可寫的話，須要將該節點轉移到主副本節點才能夠

咱們將AO1\ALWAYON下的AG下的HA-GP1從從副本轉移到主副本咱們再次插入數據

轉移完成


咱們再次嘗試插入數據

咱們從SQLCLUSTER集羣節點查看數據是否同步

咱們再次到SQLCLUSTER節點插入數據，提示錯誤
緣由是節點屬於AO1

可是咱們查看數據，從當前節點從AO1插入的數據依然能夠同步到SQLCLUSTER

各副本間的數據同步
AlwaysOn必需要維護各副本間的數據一致性，當主副本上的數據發生變化，會同步到輔助副本上。這裏AlwaysOn經過三個步驟來完成：
步驟1：主副本記錄發生變化的數據；
步驟2：將記錄傳輸到各個輔助副本；
步驟3:把數據變化操做在輔助副本上執行一遍。
具體實現以下：
在主副本和輔助副本上，SQL Server都會啓動相應的線程來完成相應的任務。對於通常的SQL Server服務器，即沒有配置高可用性，會運行Log Writer的線程，當發生數據修改事務時，此線程負責將本次操對應的日誌信息記錄到日誌緩衝區中，而後再寫入到物理日誌文件。但若是配置了AlwaysOny主副本的數據庫，SQL Server會爲它創建一個叫Log Scanner的線程，不間斷的工做，負責將日誌從日誌緩衝區或日誌文件裏讀出，打包成日誌塊，發送到輔助副本。所以能夠保證發生的數據變化，不斷送給各輔助副本。
輔助副本上存在固化和重作兩個線程完成數據更新操做，固化線程會將主副本Log Scanner所發過來的日誌塊寫入輔助副本磁盤上的日誌文件裏，所以稱爲固化，而後重作線程負責從磁盤上讀取日誌塊，將日誌記錄對應的操做重演一遍，此時主副本和輔助副本上的數據就一致了。重作線程每隔固定的時間點，會跟主副本通訊，告知本身的工做進度。主副本由此知道兩邊數據的差距。Log Scanner負責傳送日誌塊，不須要等待Log Writer完成日誌固化；輔助副本完成日誌固化之後就會發送消息到主副本，告知數據傳輸完成，而不須要等待重作完成，這樣各自獨立的設計，是儘量減小 AlwaysOn所帶來的操做對數據庫性能的影響。