always on 完整方案

【Always On】完整文檔

有道雲筆記markdown文檔。

概述

• 發布訂閱：alwayson之前的技術實現方案---SQL Server 2005,微軟,查詢分離。
  缺點：生產庫和查詢庫的同步性能較差，存在性能問題，因此在大型生產環境為人詬病。
• AlwaysOn:SQL Server 2012
  引入的一種新的技術架構，相比發布訂閱性能明顯提升;區別在於其充分利用內存高效讀取的原理來實現日志的傳遞。

功能

原理

同步操作：

從客戶端收到事務后，主副本會將事務的日志寫入事務日志，同時將該日志記錄發送到輔助副本。
日志記錄寫入主數據庫的事務日志后，事務將不能撤消，除非在此時故障轉移到尚未收到該日志的輔助副本。主副本將等待來自同步提交輔助副本的確認。
輔助副本將強制寫入日志（固化），並將確認消息返回給主副本。
收到來自輔助副本的確認后，主副本將完成提交處理並向客戶端發送一條確認消息。

客戶端->>主副本: 提交事務
主副本->>主副本: 事務的日志寫入事務日志
主副本->>輔助副本: 日志記錄
輔助副本->>輔助副本:寫入日志（固化）
輔助副本->>輔助副本:日志轉換成修改操作，寫入數據庫（重做）
輔助副本->>主副本: 確認消息
主副本->>主副本: 完成提交
主副本->>客戶端: 確認消息

線程介紹以及職責

LogWriter 任何一個SQL Server 數據修改事務 內存緩沖 日志固化

graph LR
日志信息-->內存日志緩沖區
內存日志緩沖區-->物理日志文件

Log Scanner 主副本 日志緩沖區或者日志文件 打包日志塊 不間斷工作 發送給各個輔助副本

graph LR
內存日志緩沖區/物理日志文件-->日志塊
日志塊-->輔助副本

Harden 寫入輔助副本的磁盤上的日志文件

Redo 日志記錄翻譯成數據修改操作 每隔固定的時間跟主副本通信 告知自己的工作進度

graph LR
Harden日志塊-->存放到輔助副本磁盤日志文件
存放到輔助副本磁盤日志文件-->Redo日志塊
Redo日志塊-->數據修改操作

1. 任何一個SQL Server里都有個叫Log Writer的線程，當任何一個SQL用戶提交一個數據修改事務時，它會負責把記錄本次修改的日志信息先記入一段內存中的日志緩沖區，然后再寫入物理日志文件（日志固化）,所以對於任何一個數據庫，日志文件里都會有所有數據變化的記錄。

2. 對於配置為AlwaysOn主副本的數據庫，SQL Server會為它建立一個叫Log Scanner的工作線程,這個線程專門負責將日志記錄從日志緩沖區或者日志文件里中讀出，打包成日志塊，發送給各個輔助副本。由於它的不間斷工作，才使主副本上的數據變化，可以不斷地向輔助副本上傳播。

3. 在輔助副本上，同樣會有兩個線程，完成相應的數據更新動作，它們是固化（Harden）和重做（Redo）。

   1. 固化線程會將主副本Log Scanner所發過來的日志塊寫入輔助副本的磁盤上的日志文件里（這個過程被稱為"固化"）。
   2. 重做線程，則負責從磁盤上讀取日志塊，將日志記錄翻譯成數據修改操作，在輔助副本的數據庫上完成。當重做線程完成其工作以后，輔助副本上的數據庫就會跟主副本一致了。AlwaysOn就是通過這種機制，保持副本之間的同步。重做線程每隔固定的時間點，會跟主副本通信，告知它自己的工作進度。主副本就能夠知道兩邊數據的差距有多遠。

注意：這些線程在工作上各自獨立，以達到更高的效率。Log Scanner負責傳送日志塊，而無須等待Log Writer完成日志固化；輔助副本完成日志固化以后就會發送消息到主副本，告知數據已經傳遞完畢，而無須等待重做完成。其設計目標，是盡可能地減少AlwaysOn所帶來的額外操作對正常數據庫操作的性能影響。

部署

所需資源

指標	域控服務器	DB1	DB2	共享文件夾or見證磁盤
IP	域控IP	DB1 IP	DB2 IP
網關	172.31.2.254	172.31.2.254	172.31.2.254
子網掩碼	255.255.255.0	255.255.255.0	255.255.255.0
DNS	127.0.0.1	域控IP	域控IP
計算機名	Cluster01	DBserver01	DBserver02
域名	*.com	*.com	*.com
域賬戶	username
域密碼	******
仲裁見證文件共享地址				（\\share）共享地址 Tip：不能在域控上
VIP（故障轉移集群虛擬IP）	172.31.1.E
SQL數據庫版本		SQL Server 2016 Enterprise Edition	SQL Server 2016 Enterprise Edition
SSMS		Server Management Studio 17.4	Server Management Studio 17.4
服務器版本	Windows Server 2012 R2 Standand  64位	Windows Server 2012 R2 Standand  64位	Windows Server 2012 R2 Standand  64位
VIP（alwayson虛擬IP）		Always On IP	Always On IP
偵聽器	偵聽器名稱
數據庫	dbname
sa密碼	******

系統架構

• windows 群集

graph TD

故障轉移群集_VIP1--> 節點服務器1_IP1
故障轉移群集_VIP1--> 節點服務器2_IP2
故障轉移群集_VIP1--> 節點服務器X_IPX....

• always on 集群

graph TD

數據庫偵聽器_VIP2--> DBServer01_IP1
數據庫偵聽器_VIP2--> DBServer02_IP2
數據庫偵聽器_VIP2--> DBServer0X_IPX....

搭建步驟

1. Part1域控配置
2. Part2故障轉移集群配置
3. Part3AlwaysOn集群配置
4. Part4典型問題分析

擴展優化

技術要點

• 四種集群仲裁配置

• [ ] 多數節點：這種配置不會用到仲裁磁盤，而所謂多數節點就是在正常節點數量占多數的情況下，集群才會提供服務，否則就停止服務。這種配置適用於奇數節點的集群，例如5個節點的集群，其正常節點數量必須至少3個，集群才會提供服務

• [ ] 多數節點和磁盤：適用於偶數節點的集群，他在計算法定數量時會將仲裁磁盤計算進來，例如，4個節點+1個仲裁磁盤節點的集群，可以將其視為5個節點的集群，這時正常節點數量必須至少3個，集群才會提供服務

• [x] 多數節點和文件共享：它和（多數節點和磁盤）類似，不過仲裁磁盤改為共享文件夾內的文件

• [ ] 沒有多數：只有磁盤，只要仲裁磁盤脫機，集群就會停止提供服務（不建議使用，這種方式很早之前已經有了）

注意：
1. 仲裁配置：（多數節點） 和 （多數節點和文件共享）
2. 如果集群節點是奇數，那么使用多數節點。
3. 如果集群節點是偶數，那么使用多數節點和文件共享。
4. 需要配置一個共享文件夾，各個節點都能訪問這個共享文件夾。
5. 共享文件夾所在機器不需要加入域。
6. 生產環境不要把共享文件夾放在域控上。
7. 一個節點和見證磁盤運行,可以運行。
8. 所有節點運行，見證磁盤不通信，停止運行。

• 見證磁盤 VS 見證共享文件夾

• [ ] 見證磁盤（簡稱仲裁盤）需要共享存儲，各個服務器節點需要掛載同一個磁盤是放在共享存儲上面。

• [x] 見證共享文件夾：Windows 2008推出的見證磁盤方式，推出見證共享文件夾之后可以不需要共享存儲，只需要共享文件夾即可。

• 同步提交 VS 異步提交

• [ ] 異步提交模式：使用此可用性模式的可用性副本稱為"異步提交副本"。
  當輔助副本處於異步提交模式下或者盡管輔助副本在同步提交模式下，但此時主副本在異步提交模式時，主副本無須確認該輔助副本是否已經完成日志固化，就可以提交事務。因此，主數據庫事務提交不會受到輔助數據庫的影響而產生等待。但是，輔助數據庫的更新可能會滯后於主數據庫，如果發生故障轉移，可能會導致某些數據丟失。因此這種可用模式適合於可用性副本的分布距離較遠的情況。

• [x] 同步提交模式：使用此可用性模式的可用性副本稱為"同步提交副本"。
  同步提交模式要求主副本和輔助副本必須設置成同步提交副本。在同步提交模式中，主副本必須確認輔助副本已經完成日志固化才可以提交事務（不需要等待輔助副本完成日志重做），這樣就保證兩邊的數據始終是同步的。但是這種保障的代價是主數據庫上的事務提交會有滯后時間。可以說，同步提交模式相對於性能而言更強調高可用性。

• 故障轉移集群VIP VS AlwaysOn 的VIP

• [x] 1. 故障轉移集群VIP：連接故障轉移集群管理器的集群使用

• [x] 2. AlwaysOn VIP 連接AlwaysOn使用

• 故障轉移模式

  可用性副本的主角色和輔助角色在稱為“故障轉移” 的過程中通常是可互換的。

    三種故障轉移形式：
    1. 自動故障轉移（無數據丟失）
    1. 計划的手動故障轉移（無數據丟失）
    1. 強制手動故障轉移（可能丟失數據）,通常稱為“強制故障轉移”
  

• 自動故障轉移所需條件

僅在以下條件下才發生自動故障轉移：

• [x] 存在自動故障轉移集。 此自動故障轉移集由主要副本和次要副本（自動故障轉移目標）構成，主要副本和次要副本都配置為同步提交模式並且設置為自動故障轉移。
  如果主要副本設置為手動故障轉移，即使次要副本設置為自動故障轉移，也無法發生自動故障轉移
  自動故障轉移目標具有正常運行的同步狀態（這指示故障轉移目標上的每個輔助數據庫都與其相應的主數據庫同步）。
• [x] Windows Server 故障轉移群集 (WSFC) 群集具有仲裁。
• [x] 主副本已變得不可用，並且由靈活的故障轉移策略定義的故障轉移條件級別已得到滿足。

注意：

1. 在數據庫級別，諸如因數據文件丟失而使數據庫成為可疑數據庫、刪除數據庫或事務日志損壞之類的數據庫問題不會導致可用性組進行故障轉移

2. AlwaysOn 可用性組監視自動故障轉移集中兩個副本的運行狀況。 如果任一副本失敗，則該可用性組的運行狀況狀態將設置為“嚴重”。 如果輔助副本失敗，則自動故障轉移將不可行，因為自動故障轉移目標不可用。 如果主副本失敗，則可用性組將故障轉移到輔助副本。 在之前的主副本進入聯機狀態之前，將不存在任何自動故障轉移目標。 在任一情況下，為了在連續出現失敗這種近乎不可能發生的情況下確保可用性，我們建議您將其他輔助副本配置為自動故障轉移目標。

3. 要設置故障轉移模式為“自動”的前提是可用性模式是“同步提交”。

4. 如果主要副本設置為手動故障轉移，即使次要副本設置為自動故障轉移，也無法發生自動故障轉移。

5. 只能設置一個自動故障轉移輔助副本

• 輔助角色支持的連接訪問類型

• [ ] 無連接
  不允許任何用戶連接。 輔助數據庫不可用於讀訪問。 這是輔助角色中的默認行為。

• [ ] 僅讀意向連接
  輔助數據庫僅適用於其 Application Intent 連接屬性設置為 ReadOnly 的連接（讀意向連接）。

• [x] 允許任何只讀連接
  輔助數據庫全部可用於讀訪問連接。 此選項允許較低版本的客戶端進行連接。

• 主角色支持的連接訪問類型

• [x] 1.允許所有連接
  主數據庫同時允許讀寫連接和只讀連接。 這是主角色的默認行為。

• [ ] 2.僅允許讀/寫連接
  當 Application Intent 連接屬性設置為 ReadWrite 或未設置時，允許此連接。 不允許其 Application Intent 連接字符串關鍵字設置為 ReadOnly的連接。 僅允許讀寫連接可幫助防止您的客戶錯誤地將讀意向工作負荷連接到主副本。

注意：所有的限制只針對配置了可用性數據庫，非可用性數據庫不受這些連接的限制，配置讀寫分離至少得保證有`兩個可讀副本`，如果只有一個可讀副本當可讀副本變成了主副本之后會導致只讀意向`無副本可連接`。

注意事項

• 所有機器防火牆都關掉
• 域控不需要安裝故障轉移集群服務和SQL Server.不需要加入到故障轉移集群
• 兩個節點都需要安裝相同的更新程序，建議不要開啟自動更新功能，由系統管理員手動更新
• SQL Server 2012 AlwaysOn只支持最多一個主副本和四個輔助副本.
• 最多允許三個同步提交的可用性副本(包括主副本)
• 最多允許兩個自動故障轉移副本(包括主副本)
• 現在AlwaysOn可用性組已經完全支持 Windows Azure ，可以把輔助副本部署到 Windows Azure 上
• 主副本機器和各個輔助副本機器的扇區是否一致，如果扇區不一致，或者環境不一樣有可能導致同步慢或IP沖突問題
• 每個扇區字節數和每個物理扇區字節數這兩個值，各個副本顯示不同，那么最好不要搭建AlwaysOn
• 在AD用戶和計算機管理界面 里的 域用戶和故障轉移集群用戶的權限需要添加下面紅框的權限，否則創建偵聽器的時候有可能報錯

跳坑記錄

• [x] 1.數據庫處於“正在還原”問題
• 原因分析：
  數據庫加入可用性組后，正常狀態下數據庫為標注為“已同步”，當刪除可用性后，數據庫狀態會變成“正在還原”該狀態數據庫將無法正常讀寫。
• 解決方案：執行基本還原即可。

--修復正在還原數據庫 
RESTORE DATABASE omsprod WITH RECOVERY

• [x] 2.孤立用戶問題
• 原因分析：數據庫備份還原后數據的登錄名的用戶映射關系丟失，數據庫登錄lcoms9999成為孤立用戶，進而服務端連接數據庫連接失敗。
• 解決方案：執行以下腳本數據庫刪除原有的數據庫登錄名修復數據的孤立用戶。

--查詢孤立用戶 --需要選定對應的數據庫
sys.sp_who @loginame ='LCOMS9999' -- sysname
--刪除登錄用戶
KILL 71
--修復孤立用戶 --需要選定對應的數據庫
sp_change_users_login 'Auto_Fix', 數據庫用戶名, NULL, '密碼'

• [x] 3.故障轉移后，服務端連接數據庫節點失敗問題。
• 原因分析：數據庫副本之間的sid不一致。
• 修復方案：執行腳本獲取sid，將主要副本的登錄用戶的sid 同步到服務副本中。

--查詢登錄名sid --主庫查詢sid --將結果在輔助庫中執行
SELECT
  'create login [' +p.name + '] ' +
  case when p.type in('U','G') then 'from windows ' else '' end +
 'with ' +
 case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) + ' hashed, ' +
 'sid = ' + master.sys.fn_varbintohexstr(l.sid) +
  ',check_expiration = ' + case when l.is_expiration_checked >0 then 'ON, ' else 'OFF, ' end +
  'check_policy= ' + case when l.is_policy_checked> 0 then 'ON, ' else 'OFF, ' end +
 case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
  else '' end +
 'default_database = ' + p.default_database_name+
 case when len(p.default_language_name) >0 then ',default_language = ' + p.default_language_name else '' end
FROM sys.server_principals p
LEFT JOIN sys.sql_logins l ON p.principal_id = l.principal_id
LEFT JOIN sys.credentials c ON  l.credential_id= c.credential_id
WHERE p.type in('S','U','G')
AND p.name<> 'sa'

• [x] 4.可用性組創建失敗問題

• 原因分析：AlwaysOn集群創建失敗刪除后，需要重新停用、啟用alwaysOn功能

• 解決方案：在每個數據庫節點的數據庫配置管理器上數據庫服務的屬性中重新停用、啟用alwaysOn功能。

• [x] 5.數據庫連接字符串配置異常導致的數據庫轉移后失去連接問題

• 原因分析：數據庫連接字符串對應到當前主要副本數據庫，發生故障轉移時數據庫連接無法自動轉移到原輔助副本中。

• 解決方案：更新數據的連接方式，將數據庫連接到alwaysON的偵聽器的虛擬IP上。當故障發生轉移后數據庫連接地址會自動的轉移到新的主要副本數據庫中。

• [x] 6.數據庫某一節點發生不可修復的故障時，需要重新部署數據庫節點。

• 解決方案：修復數據庫節點問題后，移除輔助副本的omsprod數據庫，移除Alwayson集群的可用性組中的omsprod可用性數據庫，重新添加該可用性數據庫到可用性組中。

• [x] 7.數據庫某一節點發生不可修復的故障時，需要重新部署數據庫節點。

• 解決方案：重新搭建一服務器虛擬機環境，使用服務器快照還原數據庫節點。下一步按照步驟6執行。

• [x] 8.數據庫輔助節點無法查看的問題

• 原因分析：AlwaysON集群創建的時候可以設置集群的“可讀輔助副本”的狀態。當狀態為否時，數據將無法正常打開查看。該狀態下數據庫僅用於數據庫備份。

• 解決方案：設置“可讀性輔助副本”的狀態為是。

• [x] 9.主庫磁盤滿了導致集群故障轉移異常並且導致輔助副本同步異常修復

• 現象描述：主庫磁盤滿了,故障轉移異常,導致輔助副本同步異常

• 修復步驟:

• 1. 重新添加可用性組：失敗
• 2. 移除節點：重新添加:失敗
• 3. 重新添加到域：失敗
• 4. 重新添加到搭建，windows群集：失敗
• 5. 經檢查群集添加失敗的真實原因，主副本的防火牆個別端口被意外開啟，由於前期排查時確定過防火牆已關閉，所以懷疑是公司的安全策略導致。 成功

引用

感謝前行者分享 不完全記錄

SQL Server Alwayson概念總結

從0開始搭建SQL Server AlwaysOn系列

監控AlwaysOn可用性組的性能

Alwayson輔助副本上如何創建同步賬號