SQL Server 2016 Failover + ALwaysOn
阿新 • • 發佈：2018-01-10
所有者 檢測 禁用 ger sha 上進 定義 ecb cef 我們前面寫了很多關於SQL Server相關的文章，近期公司為了提高服務的可用性，就想到了部署AlwaysOn，之前的環境只是部署了SQL Server Failover Cluster，所以決定將雲端放一臺SQL Server來配置ALwaysOn，具體思路就是在本地的SQL Server Failover Cluster中再增加一個節點，然後將新家的節點放到Azure雲端，然後在這兩個實例之間配置AlwaysOn，部署後，有個問題就是集群之間無法自動故障轉移，需要手動幹預才可以具體後期我們再做詳細介紹，廢話就不多說了，開始實踐配置；
環境介紹：
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服務器：
然後安裝ISCSI目標服務器
我們安裝後，我們打開ISCSI管理---創建ISCSI虛擬磁盤
我們新選擇DATA盤
我們增加需要分配磁盤的計算機IP
我們增加兩臺SQL Server服務器
確認信息
創建完成
再次新建一個虛擬磁盤用於仲裁
設置磁盤名稱
所有的磁盤已增加完成
我們開始從5.41上通過ISCSI連接程序連接共享磁盤
提示確認啟動服務
輸入ISCSI服務器地址，快速鏈接
已連接
卷和設備已加載
我們此時就可以在192.168.5.41上看見分配的兩塊磁盤了
我們同理也按照上面的方法，在192.168.5.42上進行ISCSI鏈接
準備好以上操作後，我們就可以開始安裝故障轉移集群了；
安裝完成
安裝後，我們同樣在第二臺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
接著我們配置 ALwaysOn，我們準備了一臺SQL服務器
但是也需要加入到集群節點；
我們現在在群集節點上增加節點，將第三臺SQL加入該節點
輸入新節點的名稱
驗證通過
測試通過後，直接增加節點
節點增加完成
我們再次查看節點信息
我們接著安裝獨立SQL實例
我們安裝功能角色
必須要命名一個實例，因為已經在集群中創建了一個默認實例；如果你已在群集中裝了一個SQL群集實例，則再在群集中的節點上安裝SQL實例時（無論單機
還是群集的），不能再使用這個實例名稱。也就是說你已經在群集節點1、2上裝了群集的SQL
默認實例的話，則在節點3上也不能再安裝單機的SQL默認實例。這種情況下可以選擇在節點
上3安裝一個SQL命名實例，
定義賬戶信息
服務器配置信息
數據目錄我們定義到本地即可
安裝完成
節點三安裝完後，我們發現服務沒有端口，默認額SQL 端口是1433，所以我們修改默認端口---SQL Server配置管理中
然後在它和之前的SQL群集實例之間創建AlwaysOn可用性組關系。另外AlwaysOn功能的開啟是在實例級設置的，這裏你一共有2個SQL實例，所以就需要對這2
個SQL實例分別進行設置。對於SQL群集實例，在其任一所有者節點上使用SQL Server
configuration manager設置一次就可以了（重啟SQL服務後生效）。
我們通過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所帶來的操作對數據庫性能的影響。
環境介紹：
Hostname：DC1
Role：DC
IP:192.168.5.20
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服務器：
然後安裝ISCSI目標服務器
我們安裝後，我們打開ISCSI管理---創建ISCSI虛擬磁盤
我們新選擇DATA盤
我們增加需要分配磁盤的計算機IP
我們增加兩臺SQL Server服務器
確認信息
創建完成
再次新建一個虛擬磁盤用於仲裁
設置磁盤名稱
所有的磁盤已增加完成
我們開始從5.41上通過ISCSI連接程序連接共享磁盤
提示確認啟動服務
輸入ISCSI服務器地址，快速鏈接
已連接
卷和設備已加載
我們此時就可以在192.168.5.41上看見分配的兩塊磁盤了
我們同理也按照上面的方法，在192.168.5.42上進行ISCSI鏈接
準備好以上操作後，我們就可以開始安裝故障轉移集群了；
安裝完成
安裝後，我們同樣在第二臺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
接著我們配置 ALwaysOn，我們準備了一臺SQL服務器
但是也需要加入到集群節點；
我們現在在群集節點上增加節點，將第三臺SQL加入該節點
輸入新節點的名稱
驗證通過
測試通過後，直接增加節點
節點增加完成
我們再次查看節點信息
我們接著安裝獨立SQL實例
我們安裝功能角色
必須要命名一個實例，因為已經在集群中創建了一個默認實例；如果你已在群集中裝了一個SQL群集實例，則再在群集中的節點上安裝SQL實例時（無論單機
還是群集的），不能再使用這個實例名稱。也就是說你已經在群集節點1、2上裝了群集的SQL
默認實例的話，則在節點3上也不能再安裝單機的SQL默認實例。這種情況下可以選擇在節點
上3安裝一個SQL命名實例，
定義賬戶信息
服務器配置信息
數據目錄我們定義到本地即可
安裝完成
節點三安裝完後，我們發現服務沒有端口，默認額SQL 端口是1433，所以我們修改默認端口---SQL Server配置管理中
然後在它和之前的SQL群集實例之間創建AlwaysOn可用性組關系。另外AlwaysOn功能的開啟是在實例級設置的，這裏你一共有2個SQL實例，所以就需要對這2
個SQL實例分別進行設置。對於SQL群集實例，在其任一所有者節點上使用SQL Server
configuration manager設置一次就可以了（重啟SQL服務後生效）。
我們通過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 Failover + ALwaysOn