SQL Server 2016 Failover Cluster + ALwaysOn

SQL Server 2016 Failover Cluster + ALwaysOn 環境的搭建

近期公司爲了提升服務的可用性，就想到了部署AlwaysOn，以前的環境只是部署了SQL Server Failover Cluster，因此決定將雲端放一臺SQL Server來配置ALwaysOn，具體思路就是在本地的SQL Server Failover Cluster中再增長一個節點，而後將新家的節點放到Azure雲端，而後在這兩個實例之間配置AlwaysOn，部署後，有個問題就是集羣之間沒法自動故障轉移，須要手動干預才能夠具體後期咱們再作詳細介紹，廢話就很少說了，開始實踐配置；
環境介紹：

Hostname：DC1
Role：DC
IP:192.168.5.20
Domain：ixmsoft.com
Hostname：ISCSI
IP:192.168.5.38
Role:Storage
Hostname：S1
Role：SQL Server 2016
IP:192.168.5.41
Hostname：S2
Role：SQL Server 2016
IP:192.168.5.42
Hostname：AO1
Role：SQL Server 2016
IP:192.168.5.43
SQL-CLUSTER
192.168.5.46
SQLCLUSTER
192.168.5.47
HA-LP1
ListenIP：192.168.5.48

由於要作磁盤共享，因此咱們使用系統自帶的ISCSI作爲鏈接器；
咱們首先安裝配置ISCSI服務器：
首先是掛載兩塊盤：一塊是Data：50G，一塊是仲裁：10G

而後安裝ISCSI目標服務器

咱們安裝後，咱們打開ISCSI管理---建立ISCSI虛擬磁盤

咱們新選擇DATA盤

咱們增長鬚要分配磁盤的計算機IP
咱們增長兩臺SQL Server服務器

確認信息

建立完成


再次新建一個虛擬磁盤用於仲裁

設置磁盤名稱

全部的磁盤已增長完成

咱們開始從5.41上經過ISCSI鏈接程序鏈接共享磁盤

提示確認啓動服務

輸入ISCSI服務器地址，快速連接

已鏈接

卷和設備已加載

咱們此時就能夠在192.168.5.41上看見分配的兩塊磁盤了

咱們同理也按照上面的方法，在192.168.5.42上進行ISCSI連接
準備好以上操做後，咱們就能夠開始安裝故障轉移集羣了；
咱們首先在S1上進行操做安裝

安裝完成

安裝後，咱們一樣在第二臺S2上進行安裝，安裝後，咱們就打開集羣管理器
右擊故障轉移集羣管理器----驗證配置

增長兩臺SQL Server服務器

驗證經過後，點擊完成

驗證經過後，咱們就能夠建立了；
咱們定義集羣名稱及IP
SQL-CLUSTER
192.168.5.46

定之後，確認信息

開始建立集羣

定義完成

兩個節點信息

磁盤信息

配置仲裁

高級仲裁選項

選擇全部節點

選擇仲裁磁盤

咱們同時將第一個磁盤增長到羣集共享卷

咱們準備安裝SQL Server 2016

定義SQL Server網絡名稱
SQLCLUSTER

選擇數據磁盤

定義羣集網絡IP
192.168.5.47

定義帳戶信息

定義數據目錄，自動選擇磁盤共享卷目錄

安裝完成

咱們在羣集管理器中就能夠看見多了一個角色及管理IP

咱們準備安裝第二個節點

下一步便可

默認便可

確認信息


節點增長完成

測試集羣
咱們從節點1切換到節點2

切換中

切換完成

咱們使用SSMS進行鏈接測試
咱們使用SQL集羣地址進行鏈接

咱們使用羣集網絡地址連接

咱們查看集羣屬性----集羣化--true

到此咱們SQL Server的Failover Cluster已經配置完成。。

SQL Server 2016 Failover + ALwaysOn功能配置介紹

咱們上一篇介紹了SQL Server 2016 Failover Cluster的配置，今天咱們繼續上一篇沒有完成的配置介紹，準備增長一個節點，而後配置實現AlwaysOn配置，實現SQL Server 2016 Failover Cluster+ ALwaysOn達到SQL Server的單點故障及高可用性，SQL Server 2016 Failover Cluster已經完成了配置，接着咱們配置 ALwaysOn，咱們準備了一臺SQL服務器，可是也須要加入到集羣節點；咱們下面是上節的配置介紹圖；
Hostname：DC1
Role：DC
IP:192.168.5.20
Domain：ixmsoft.com
Hostname：ISCSI
IP:192.168.5.38
Role:Storage
Hostname：S1
Role：SQL Server 2016
IP:192.168.5.41
Hostname：S2
Role：SQL Server 2016
IP:192.168.5.42
Hostname：AO1
Role：SQL Server 2016
IP:192.168.5.43
SQL-CLUSTER
192.168.5.46
SQLCLUSTER
192.168.5.47
HA-LP1
ListenIP：192.168.5.48

咱們首先在新的節點上安裝集羣故障轉移角色

咱們如今在羣集節點上增長節點，將第三臺SQL加入該節點

輸入新節點的名稱

驗證經過

測試經過後，直接增長節點

節點增長完成

咱們再次查看節點信息

咱們接着安裝獨立SQL實例

咱們安裝功能角色

必需要命名一個實例，由於已經在集羣中建立了一個默認實例；若是你已在羣集中裝了一個SQL羣集實例，則再在羣集中的節點上安裝SQL實例時（不管單機
仍是羣集的），不能再使用這個實例名稱。也就是說你已經在羣集節點一、2上裝了羣集的SQL
默認實例的話，則在節點3上也不能再安裝單機的SQL默認實例。這種狀況下能夠選擇在節點
上3安裝一個SQL命名實例，

定義帳戶信息

服務器配置信息

數據目錄咱們定義到本地便可

安裝完成

節點三安裝完後，咱們發現服務沒有端口，默認額SQL 端口是1433，因此咱們修改默認端口---SQL Server配置管理中

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所帶來的操做對數據庫性能的影響。

SQL Server 2016 ALwaysOn 增多個客戶端訪問點(偵聽器)

高文龍 關注 0人評論 1181人閱讀 2018-01-11 11:00:12

咱們前面3片文章介紹了SQL Server 2016 Failover Cluster+ ALwaysOn的完整配置，今天咱們介紹一下若是給ALwaysOn增長多個客戶端訪問點，常規狀況下，每一個可用性組只有一個單獨的可用性組偵聽器（Listener），可是在某些極端狀況下可能會對相同的可用性組建立多個偵聽器。好比一些歷史遺留問題。此時可能須要建立一個額外的偵聽器用於硬編碼。
可是，經過圖形化界面（SSMS）、T-SQL甚至PowerShell都不能建立第二個偵聽器，必須使用Failover Cluster Manager來實現。咱們在咱們的「SQLAG」角色內建立一個客戶端接入點（Client Access Point）資源。按下面步驟：
咱們打開故障轉移羣集管理器----角色---選擇AG---增長資源--客戶端訪問點

咱們就能夠定義客戶端訪問點名稱及對應的訪問點IP

確認信息

增長完成

此時咱們就能夠在角色---AG下看見兩個訪問名稱及IP地址

狀態是部分運行中

咱們資源---發現剛纔新增長的是脫機狀態

此時咱們右鍵新的客戶端訪問點並選擇屬性：

依賴關係

選擇以前的監聽器

咱們右擊聯機便可

聯機後，咱們用這兩個監聽器地址均可以連接管理的

 

SQL Server 2016 Failover +AlwaysOn 增長數據庫到可用性組

高文龍 關注 0人評論 1611人閱讀 2018-01-11 11:20:30

SQL Server Failover +AlwaysOn 增長數據庫到可用性組
前面幾篇文章都已經詳細介紹了SQL Server Failover +AlwaysOn 的配置，今天咱們主要介紹SQL Server Failover Cluster+AlwaysOn下 增長數據庫到可用性組
咱們首先須要建立一個數據庫及表

數據庫名稱
HAGroupDB2

建立表

給表插入數據

咱們把這個數據庫增長到高可用性組中；當前新建的數據庫沒有同步

咱們再高可用性組下增長數據庫

提示須要咱們完整備份一下

因此咱們備份

咱們同時也備份事務日誌

備份完成後，咱們換須要將備份的數據庫和事物log在節點3上進行還原

還原數據庫

還原時候，選項中必須選擇還原狀態：RESTORE WITH NORECOVERY

數據庫還原完成

咱們查看還原狀態

再還原事物日誌


還原選項---咱們選擇第二個選項---RESOTRE WITH NORECOVERY

還原完成

咱們還原了數據庫和事務日誌後，數據庫的狀態未正在還原狀態

接下來咱們就開始增長數據庫到AG中了

咱們選擇Join only

咱們連接已存在的副本服務器

鏈接成功

加入成功

咱們查看AG中的數據庫信息

查看集羣數據庫的狀態，也成爲了已同步


咱們查看面板，一切正常

綜合上面的操做，咱們可使用powershell來完成

$DatabaseBackupFile = "\\share\backups\MyDatabase.bak"  
$LogBackupFile = "\\share\backups\MyDatabase.trn"  
$MyAgPrimaryPath = "SQLSERVER:\SQL\PrimaryServer\InstanceName\AvailabilityGroups\MyAg"  
$MyAgSecondaryPath = "SQLSERVER:\SQL\SecondaryServer\InstanceName\AvailabilityGroups\MyAg"  

Backup-SqlDatabase -Database "MyDatabase" -BackupFile $DatabaseBackupFile -ServerInstance "PrimaryServer\InstanceName"  
Backup-SqlDatabase -Database "MyDatabase" -BackupFile $LogBackupFile -ServerInstance "PrimaryServer\InstanceName" -BackupAction 'Log'  

Restore-SqlDatabase -Database "MyDatabase" -BackupFile $DatabaseBackupFile -ServerInstance "SecondaryServer\InstanceName" -NoRecovery  
Restore-SqlDatabase -Database "MyDatabase" -BackupFile $LogBackupFile -ServerInstance "SecondaryServer\InstanceName" -RestoreAction 'Log' -NoRecovery  

Add-SqlAvailabilityDatabase -Path $MyAgPrimaryPath -Database "MyDatabase"  
Add-SqlAvailabilityDatabase -Path $MyAgSecondaryPath -Database "MyDatabase"

©著做權歸做者全部：來自51CTO博客做者高文龍的原創做品，如需轉載，請註明出處，不然將追究法律責任