官方文檔https://docs.microsoft.com/zh-cn/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-2017

Alwayson相對于數據庫鏡像最大的優勢就是可讀副本，帶來可讀副本的同時還添加了一個新的功能就是配置只讀路由實現讀寫分離
AlwaysOn技術集中了故障轉移群集、數據庫鏡像和日志傳送三者的優點，但又不相同。故障轉移群集的單位是SQL實例，數據庫鏡像和日志傳送的單位是單個用戶數據庫，而AlwaysOn支持的單位是可用性組，每個組中可以包括一個或者是多個用戶數據庫。也就是說，一旦發生切換，則可用性組中的所有數據組會作為一個整體進行切換。
AlwaysOn底層依然采用Windows故障轉移群集的機制進行監測和轉移，因此也需要先建立Windows Cluster，只不過可用性組中的數據庫不一定非要再存放在共享存儲上了。可以是存儲在本地磁盤上。
各副本推薦使用單機模式的SQL Server，那么數據庫副本就存放在該運行該實例節點的本地磁盤上；如果可用性副本是個群集實例，那么數據庫副本就存放在共享磁盤上。
可用性組從Windows群集角度來看，就是一個SQL級別的群集資源，其中的所有數據庫作為一個整體在節點間進行故障轉移，當然這不包括系統數據庫，系統數據庫是不能加入高可用性組中的。

因為需要借助Windos群集實現監控和轉移，所以AlwaysOn會受到一些限制：
一個可用性組中的所有可用性副本必須運行在單一的Windows群集上，跨不同Windows群集的SQL Server實例不能配置成一個AlwaysOn可用性組。
一個可用性組中的所有可用性副本必須運行在Windows群集的不同節點上。運行在同一個節點上的兩個不同實例不能用作同一個可用性組的副本。
一個數據庫只能屬于一個可用性組。
AlwaysOn最多可以支持五個副本，但只有一個可用性副本上運行的數據庫是處于可讀寫狀態。這個可讀寫的數據庫被稱為主數據庫（PrimaryDatabase），同時這個可用性副本被稱為主副本（primaryreplica）。其余的副本都被稱為輔助副本（secondaryreplica），輔助副本上的數據庫可能是不可訪問的，或者是只能接受只讀操作（取決于可用性組的配置），這些數據庫被稱為輔助數據庫。一但發生故障轉移，任何一個輔助副本都可以成為新的主副本實例。主副本會不斷地將主數據庫上的數據變化發送到輔助副本，來實現副本間的數據庫同步。

一些基本概念

FCI：Failover Cluster Instance故障集群實例，FCI是實例層面的而always on是數據庫層面的，FCI的概念有點類似ORACLE的RAC，但是實際FCI只有一個實例具備讀寫的功能
FCI在實例層面運作，而AlwaysOn是在庫層面運作。
FCI是遷移服務器硬件，不提供單個或多個數據庫的遷移。需要搭配數據庫鏡像，但是鏡像是“單庫”、不可讀，AlwaysOn可用組是可以以多個庫為一個單位遷移，備庫可讀。
FCI在過去很長時間都是SQL Server的常用高可用技術。它可以在集群的任何可用節點之間進行故障轉移。其唯一缺點就是存儲。由于需要使用共享存儲，所以存儲子系統就成了單點故障的風險點。FCI是一個安裝在WSFC上的SQL Server 實例，不管是默認實例還是命名實例。這個實例最少需要這幾個資源：IP地址、網絡名、共享硬盤（N個）、SQL Server服務、SQL Server代理服務。當然這些資源對于單獨的實例而言也一樣，只是IP地址和網絡名是來自于本機，硬盤也屬于本機，而FCI則不同。一個兩節點的FCI中，SQL Server實例會使用WSFC節點都能可用的共享存儲作為SQL Server的存儲。通常這次存儲是在SAN中劃出來的LUN，FCI的部署粗略分為兩步
1、在FCI的第一個節點上運行SQL Server安裝向導，并選擇“新的SQL Server 故障轉移群集安裝”。完成第一步之后，就可以開始第二步。
2、在WSFC的其他參與節點上運行SQL Server安裝向導并選擇“向SQL Server故障轉移群集添加節點”并完成安裝。

WSFC：Windows Server Failover Cluster windows服務故障轉移群集，純粹的OS層面的東西
它是微軟高可用技術（HA）的核心組成部分。WSFC跟FCI、AlwaysOn相比，它更多的是Windows Server的一個功能，而后面兩個則是SQL Server的功能，同時，WSFC更加底層，在創建SQL Server Failover Cluster Instance、SQL Server AlwaysOn等高可用技術之前，都需要部署和配置WSFC。
WSFC可以把多臺計算機節點（純物理機、純虛擬機、物理機混合虛擬機）組合在一起并對外部應用程序提供高可用服務。服務器上的一個應用如SQL Server，可以運行在cluster的任何一個節點上，這種運行方式是通過cluster提供一個虛擬訪問點（由一個唯一IP地址和一個唯一機器名組成，或者“虛擬網絡名”）給客戶端程序作為鏈接方式。地址和虛擬名作為一個應用程序的“資源組”，在多個參與節點之間像令牌形式地被傳輸。當活動節點出現嚴重故障時，會使得活動節點停止對外服務。這時候集群服務會自動嘗試重啟當前節點或伙伴節點的資源組。從高層次的角度來說，客戶端的訪問點是沿著故障轉移伙伴節點中的所有硬盤和服務起源傳輸的。一個已集群的實例在發生故障轉移時，會引發客戶端連接的斷開，然后在其他節點可用之后馬上重連。

可用性組：就是指的DB級別的集群的組名稱
每個可用性組定義一個包含兩個或更多故障轉移伙伴（稱為可用性副本）的集合。 “可用性副本”是可用性組的組件。 每個可用性副本都承載可用性組中的可用性數據庫的一個副本。 對于某個給定可用性組，可用性副本必須位于某一WSFC群集的不同節點上的單獨SQL Server實例上。

可用性副本：就是DB級別的集群中的成員，包含主副本，輔助副本，每個副本由一些數據庫組成
對于每個可用性組，一個給定實例只能承載一個可用性副本。 但是，每個實例可用于多個可用性組。 給定的實例可以是獨立實例或 SQL Server 故障轉移群集實例 (FCI)。
每個可用性副本都被分配一個初始角色（“主角色”或“輔助角色”），角色由該副本的可用性數據庫繼承。 給定副本的角色確定它承載的是讀寫數據庫還是只讀數據庫。 其中一個副本（稱為“主副本”）被分配主角色，它承載讀寫數據庫（稱為“主數據庫”）。 至少一個其他副本（稱為“輔助副本”）被分配輔助角色。 輔助副本承載只讀數據庫（稱為輔助數據庫）。

偵聽器
AlwaysOn創建后，客戶端就需要進行連接，為了讓應用程序能夠透明地連接到主副本而不受故障故障轉移的影響，我們需要創建一個偵聽器，偵聽器就是一個虛擬的網絡名稱，可以通過這個虛擬網絡名稱訪問可用性組，而不用關心連接的是哪一個節點，它會自動將請求轉發到主節點，當主節點發生故障后，輔助節點會變為主節點，偵聽器也會自動去偵聽主節點。
一個偵聽器包括虛擬IP地址、虛擬網絡名稱、端口號三個元素，一旦創建成功，虛擬網絡名稱會注冊到DNS中，同時為可用性組資源添加IP地址資源和網絡名稱資源。用戶就可以使用此名稱來連接到可用性組中。與故障轉移群集不同，除了使用虛擬網絡名稱之外，主副本的真實實例名還可以被用來連接。

Always on的原理
1、任何一個SQL Server里都有個叫Log Writer的線程，當任何一個SQL用戶提交一個數據修改事務時，它會負責把記錄本次修改的日志信息先記入一段內存中的日志緩沖區，然后再寫入物理日志文件（日志固化）,所以對于任何一個數據庫，日志文件里都會有所有數據變化的記錄。
2、對于配置為AlwaysOn主副本的數據庫，SQL Server會為它建立一個叫Log Scanner的工作線程,這個線程專門負責將日志記錄從日志緩沖區或者日志文件里中讀出，打包成日志塊，發送給各個輔助副本。由于它的不間斷工作，才使主副本上的數據變化，可以不斷地向輔助副本上傳播。
3、在輔助副本上，同樣會有兩個線程，完成相應的數據更新動作，它們是固化（Harden）和重做（Redo）。固化線程會將主副本Log Scanner所發過來的日志塊寫入輔助副本的磁盤上的日志文件里（這個過程被稱為"固化"）。而重做線程，則負責從磁盤上讀取日志塊，將日志記錄翻譯成數據修改操作，在輔助副本的數據庫上完成。當重做線程完成其工作以后，輔助副本上的數據庫就會跟主副本一致了。AlwaysOn就是通過這種機制，保持副本之間的同步。重做線程每隔固定的時間點，會跟主副本通信，告知它自己的工作進度。主副本就能夠知道兩邊數據的差距有多遠。這些線程在工作上各自獨立，以達到更高的效率。Log Scanner負責傳送日志塊，而無須等待Log Writer完成日志固化；輔助副本完成日志固化以后就會發送消息到主副本，告知數據已經傳遞完畢，而無須等待重做完成。其設計目標，是盡可能地減少AlwaysOn所帶來的額外操作對正常數據庫操作的性能影響。
4、同步提交模式的維護方式：從客戶端收到事務后，主副本會將事務的日志寫入事務日志，同時將該日志記錄發送到輔助副本。日志記錄寫入主數據庫的事務日志后，事務將不能撤消，除非在此時故障轉移到尚未收到該日志的輔助副本。主副本將等待來自同步提交輔助副本的確認。輔助副本將強制寫入日志（固化），并將確認消息返回給主副本。收到來自輔助副本的確認后，主副本將完成提交處理并向客戶端發送一條確認消息。在同步提交可用性模式下，副本聯接到某個可用性組后，輔助數據庫就會與對應的主數據庫求得一致并進入 SYNCHRONIZED（已同步）狀態。 只要一直在進行數據同步，輔助數據庫就會保持 SYNCHRONIZED 狀態。 這可確保對主數據庫提交的每個事務也應用到對應的輔助數據庫。在同步輔助副本上的每個輔助數據庫之后，輔助副本的同步運行狀態總體上將為 HEALTHY。
5、異步提交模式的維護方式：如果每個輔助副本都在異步提交模式下運行，則主副本不會等待任何輔助副本強制寫入日志， 而會在將日志記錄寫入本地日志文件后，立即將事務確認發送到客戶端。由于主副本不會等待來自輔助副本的確認，因而輔助副本上的問題從不會影響主副本，輔助數據庫就會保持 SYNCHRONIZING 狀態。對于主副本和輔助副本相隔很遠而且您不希望小錯誤影響主副本的災難恢復方案的情況，或性能比同步數據保護更重要的情況，異步提交模式將會很有用。異步提交輔助副本會嘗試與接收自主副本的日志記錄保持一致，但異步提交輔助數據庫往往會保持未同步狀態，通常異步提交輔助數據庫和相應的主數據庫之間的這個時間差會很小。但是，如果承載輔助副本的服務器的工作負荷過高或網絡速度很慢，則這個時間差會變得較大。
6、會話超時機制：由于軟錯誤不能由服務器實例直接檢測到，因此，軟錯誤可能導致一個可用性副本無限期等待會話中另一個可用性副本的響應。 為了防止發生這種情況， Always On 可用性組實施了會話超時機制，此機制基于以下條件：所連接的可用性副本會在每個打開的連接上按固定間隔發送 ping。 在超時期限內收到 ping 指示連接仍是開放的且服務器實例正在通過此連接進行通信。 收到 ping后副本將重置此連接上的超時計數器。主副本和輔助副本相互 ping 以指示它們仍處于活動狀態， 會話超時限制是用戶可配置的副本屬性，默認值為 10 秒。如果在會話超時期限內沒有收到來自另一個副本的ping，該連接將超時、連接將關閉；超時的副本進入 DISCONNECTED 狀態。 即使為同步提交模式的副本，事務也將不等待該副本重新連接暫時將該輔助副本切換到異步提交模式。在該輔助副本重新與主副本連接后，它們將恢復同步提交模式。

仲裁配置的三種方式：
1、不配置仲裁見證：就是少數服從多數，正常節點數量占多數的情況下，集群才會提供服務，否則就停止服務。例如5個節點的集群，其正常節點數量必須至少3個，集群才會提供服務
2、配置磁盤見證：適用于偶數節點的集群，他在計算法定數量時會將仲裁磁盤計算進來，例如，4個節點+1個仲裁磁盤節點的集群，可以將其視為5個節點的集群，這時正常節點數量必須至少3個，集群才會提供服務
3、配置共享文件見證：它和配置磁盤見證類似，不過磁盤改為共享文件夾內的文件

Always on的搭建
網上手把手的教程網址https://www.linuxidc.com/Linux/2017-01/139766.htm
1、primary、secondary節點實例的所有服務器都必須先在os上安裝好故障轉移集群Failover clustering功能，一旦其中某臺服務器沒有安裝，則創建故障轉移集群時會報錯the server ‘XX’ does not have the failover clustering feature installed。OS安裝了故障轉移集群功能的話Server Manager–Manage–add roles and feature–feature–failover clustering，才會出現server manager–tools–Failover cluster manager
2、primary、secondary節點實例的服務器需要加入同一個域中
3、創建Windows服務器故障轉移集群(Windows Server Failover Cluster)時，只在其中某臺服務器比如只在primary節點實例的服務器創建即可，給集群起個名字和分配一個ip，并把所有的節點服務器加入故障轉移集群中即可(這些加入的服務器需要加上域名后綴)，此時千萬不要勾選“將所有符合條件的存儲添加到群集”，否則primary、secondary節點實例的服務器原來掛載的存儲目錄會消失。
4、配置集群仲裁選擇共享文件仲裁時，不能使用任意節點服務器本地的目錄（File share associated with file share witness resource cannot be hosted by this cluster or any of its nodes）
5、每個節點的sqlserver服務都要啟用always on的功能，這個功能開啟后需要重啟sqlserver服務以便生效
Sql Server Configuration Manager–SQL Server Serivces–SQL Server(MSSQLSERVER)–右鍵選擇Properties–Awayson High Availability–Enable AlwaysOn Availability Groups
6、在主節點數據庫實例上配置always on，實例–Always On High Availability–右鍵選擇New Availablity Group Wizard新建可用性組
7、數據庫加入always on可用性組時，右鍵高可用組名稱–add database即可，但是必須對primary節點的實例的數據庫進行full備份和log備份，并把full備份和log備份以norecovery模式恢復到secondary節點的實例
備注：需要留意主副本機器和各個輔助副本機器的扇區是否一致，如果扇區不一致有可能導致同步慢，那么最好不要搭建AlwaysOn

Always on的總結
1、primary節點數據庫創建的表、索引，會自動同步到secondary節點的數據庫
2、always on要求各個節點對應的操作系統版本必須一致，但是數據庫版本可以不一致，比如數據庫一個是sqlserver2014 sp2，一個是sqlserver2014 sp3
3、搭建always on時，各個節點的實例名稱@@servername不需要一致
4、關于IP，一個是windows故障轉移集群ip，OS級別的IP，外部可以通過這個ip登錄故障轉移集群中中的任意一臺服務器。一個是alwayson偵聽IP，是數據庫實例級別的IP，外部可以通過這個ip連上always on的任意一個數據庫實例，類似oracle的scan ip.這兩個ip對應的dns記錄都不需要預先在dns服務器中創建，而是在建立windows故障轉移集群ip(這個過程需要輸入WFC名稱和ip)和alwayson偵聽IP(這個過程需要輸入監聽名稱和ip)時會自動在dns服務器中創建
5、primary或secondary節點的數據庫都不能執行脫機操作，執行脫機操作會報錯：The operation cannot be performed on database ‘XX’ because it is involved in a database mirroring session or an availability group
6、primary或secondary節點的數據庫都不能執行分離操作，執行分離操作會報錯：The database ‘XX’ is currently joined to an availability group，before you can drop the database，you need to remove it from the availability group
7、同步提交即AG的屬性Availability Mode選擇Synchronous commit時，primary節點的數據庫后面狀態顯示(Synchronized)，secondary節點的數據庫后面狀態顯示(Synchronized)，異步提交即AG的屬性Availability Mode選擇Asynchronous commit時，primary節點的數據庫后面狀態顯示(Synchronized)，secondary節點的數據庫后面狀態顯示(Synchronizing)
8、primary節點的數據庫新增一個數據文件，secondary節點的數據庫也會新增一個數據文件，且路徑和primary節點的數據庫的一模一樣，就算secondary節點的數據庫設置了默認路徑也會忽略，比如secondary節點的數據庫的默認路徑是G:\DEFAULT.DATA，primary節點的數據庫新增文件的路徑是L:\data1.dbf，secondary節點的數據庫該文件路徑也是L:\data1.dbf，而非G:\DEFAULT.DATA\data1.dbf，所以primary節點的數據庫新增一個數據文件，secondary節點的數據庫服務器沒有一樣的路徑，secondary節點的數據庫會報錯，always on的同步會中斷
9、always on沒有正常同步，具體的處理思路是先查看primary、secondary節點的實例sqlserver log日志，看具體是什么問題
10、Always on的可用性組中移除某個數據庫的操作
以下兩條都在primary組里面操作
1、先在可用性組里面找到該數據庫右鍵點擊暫停數據傳輸
2、再在可用性組里面找到該數據庫右鍵點擊移除出AG
或
ALTER DATABASE database_name SET HADR OFF
11、主節點把數據庫從AG移除了，輔助節點的AG里面也看不到該數據庫，但是輔助節點該數據庫還存在且狀態顯示(Not Synchronzing)，這種情況說明輔助節點該數據庫還是在AG中，主節點執行ALTER DATABASE dbname SET HADR OFF報錯說該數據庫不存在，輔助節點執行ALTER DATABASE dbname SET HADR OFF不報錯但是一直等待，等待一個后臺進程。
引發原因1：主節點的日志磁盤比輔助節點的日志磁盤空間大，導致主節點的日志沒有完全同步到輔助節點，輔助節點的磁盤空間就爆掉了，而且此時主節點也沒有辦法收縮日志，所以只能從AG中取消該數據庫，主節點在AG中移除該數據庫后輔助節點AG里面也看不該數據庫了，但是輔助節點該數據庫還存在且狀態是顯示(not synchronizing未同步)
引發原因2：有需求要把某個數據庫移除出AG，再在主庫備份，再拿到從庫還原，繼續添加到AG，這時這個數據庫已經不在可用性組里面了，主庫上這個數據庫后面沒有了(Synchonized)，但是從庫這個數據庫后面還顯示(Not Synchonizing)，導致從庫無法刪除這個數據庫也沒有對這個數據庫進行restore，從庫報錯信息：unable to accesss availability database ‘XXX’ because the database replica is not in the primary or secondary role.
處理方法1：沒有好方法，只能一直等待，等待輔助節點該數據庫狀態變成(restoring恢復中)，如果嫌等待時間太長考慮方法2
處理方法2：重啟從庫，從庫這個數據庫狀態顯示 (Not Synchonizing/In Recovery)，再在從庫執行ALTER DATABASE database_name SET HADR OFF，此時從庫這個數據庫狀態顯示 (restoring)，可以刪除了
12、輔助節點某個數據庫顯示Not Synchonizing，輔助節點的AG里面數據庫顯示異常，出現紅色標記，右鍵無法顯示resume，解決方法：直接在主節點上移除，然后再添加就行
主節點實例上該數據庫顯示synchronized
副節點實例上該數據庫顯示not synchronizing，副節點-Always On High Availability-Availability Groups-AG名稱(Secondary)-Availability Databases-數據庫名稱-數據庫右下角顯示紅色，右鍵這個數據庫無法顯示resume，只有suspend、remove這幾個
13、always on主本或副本的所有數據庫的狀態都是Not Synchonizing，可用性組顯示resolving，它下面的某個副本也顯示resolving，解決方法就是重啟這個狀態為resolving的服務器
14、輔助節點某個數據庫顯示Not Synchronizing In Recovery，輔助節點的AG下這個數據庫顯示藍色標記的處理方法：在該輔助節點Always On High Availability–Availability Groups–Availability Databases下面找到報錯的數據庫顯示為藍色標記，右鍵選擇Resume Data Movement,這個時候報錯的數據庫顯示為紅色標記，過一會就開始同步了
15、輔助節點某個數據庫顯示Not Synchronizing的處理總思路，只要主副本沒有傳輸到輔助副本的日志沒有丟失，主副本還保留了這份日志，這個問題就很簡單，要么在輔助節點上選擇Resume Data Movement如上14，要么就在主節點上移除該數據庫，再把主節點數據庫的日志拿到輔助節點去restore，restore完后，再重新添加即可
16、選項readable secondary可讀取輔助副本的問題：雖然主節點也選擇了no表示不可執行select語句，但是主節點依然可以執行select，因為這個選項只對輔助副本生效，對主副本無效
17、always on的主庫做增量備份的時候，居然會使主庫的日志無法重用導致日志無法截斷，日志暴漲，原因就是select name,log_reuse_wait_desc from sys.databases第二個字段log_reuse_wait_desc值出現"活動備份或還原"就會影響日志截斷，和always on本身沒有任何關系
18、always on 取消后，windows的MDSTC服務出故障:MSDTC on server ‘XX’ is unavailable的案例
組件服務 -> 計算機 -> 我的電腦，顯示紅色箭頭的處理流程
18.1、在主節點取消always on后，最好不要去動windows OS的配置，即不要關閉主節點在windows故障轉移集群中狀態
18.2、在主節點取消always on后，如果主節點在windows故障轉移集群顯示offline，但是副節點在windows故障轉移集群顯示online，嘗試把主節點在windows故障轉移集群顯示為online，看紅色箭頭是否消失
18.3、如果上面2不行，則在主節點關閉整個windows故障轉移集群，看兩個節點是否都顯示offline，看紅色箭頭是否消失
18.4、如果上面3不行，再在主節點把windows故障轉移集群啟動，看兩個節點是否都顯示online，看紅色箭頭是否消失
18.5、如果上面4不行，則嘗試重啟主節點服務器，重啟后，看紅色箭頭是否消失
19、AG的輔助副本正在執行logshipping的backup log時，主副本手工執行backup log會被堵塞，被堵塞的原因是在等待事件類型是HADR_BACKUP_QUEUE的進程，其實就是AG的主副本不同同時備份日志
20、AG的輔助副本實例，配置了logshipping到其他服務器，這個輔助副本實例上的backup log job報錯
The backup operation on database ‘TESTDB’ was skipped because it is part of an availability group and not its preferred backup replica.
解決方法
20.1、確保輔助副本的實例名和機器名一致
20.2、在always on可用性組中的備份首選項中設置為任意副本，且輔助副本的備份優先級高于主副本，比如設置輔助副本為51，主副本為50
21、always on的主副本節點A1搭建logshipping到C服務器，報錯The backup operation on database ‘DB’ was skipped because it is part of an availability group and not its preferred backup replica.(因為它是一個可用性組和不其首選的備份副本的一部分，跳過了數據庫’數據庫名稱’’ 上的備份操作)
報錯原因：A1是主副本節點，而AG設置的備份首選項是prefer secondary，所以A1是沒有辦法備份日志的，需要在A2這個輔助副本上搭建logshipping到C服務器
繼續出現的問題：現在A2開始logshipping備份日志了，但是A1也可以執行BACKUP LOG [DB] TO DISK = N’\log\DB_LOG_YYMMDDMi.bak’
繼續出現的問題:C服務器有兩個restore job了，但是來自A2的restore job有報錯*** Error: Could not log history/error message.(Microsoft.SqlServer.Management.LogShipping) ***
*** Error: The specified agent_id 27A07B67-19A6-4BA1-A05D-52CC968B479C or agent_type 2 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***
最后解決方法是
21.1、A1也搭建logshipping，但是A11本機所有的job都是disable，但是C服務器上的job是enable
21.2、A2也搭建logshipping，A2所有的job都enable，但是C服務器上的job是disable
21.3、A1實例開啟backup log，但是備份腳本里面排除logshipping的數據庫msdb.dbo.log_shipping_primary_databases
22、AG搭建的logshipping如上例21，輔助副本A2的logshipping的備份job報錯First attempt to backup database ‘ECMDB’ to file ‘\YY\ZZ.trn’ failed because Log backup for database “ECMDB” on a secondary replica failed because the last backup LSN (0x000cb1e0:02c34336:0001) from the primary database is greater than the current local redo LSN (0x000cb1e0:02c342e1:0155). No log records need to be backed up at this time. Retry the log-backup operation later. 檢查了AG兩個節點之間的日志傳輸是正常的，沒有延遲，重啟輔助副本節點A2的sqlserver服務，發現輔助副本節點A2的logshipping的備份job也報和主副本節點A1一樣的錯誤The backup operation on database ‘ECMDB’ was skipped because it is part of an availability group and not its preferred backup replica.
至此找到原因，是因為AG主副本節點輔助副本節點之間傳輸可能出現問題，導致輔助副本節點A2一直跟不上主副本節點A1，解決方法
22.1、把ECMDB數據庫從AG中移除，對主副本節點A1的日志進行備份
22.2、把主副本節點A1備份的日志拿到輔助副本節點A2去恢復，也拿到logshipping的服務器C上去恢復
22.3、重新把ECMDB數據庫加入AG，至此輔助副本節點A2的logshipping的備份job正常了
24、AG創建AG listener報錯Access is denied的處理方法：
WFC的名稱是IBDMMDBCLS，創建好了名稱為IBDMMDBAG的AG后，在AG里面創建名稱為IBDMMDBLS的AG listener出現報錯，報錯信息在WFC的error日志中如下
Cluster network name resource ‘IBDMMDBAG_IBDMMDBLS’ failed to create its associated computer object in domain ‘dai.netdai.com’ during: Resource online.
The text for the associated error code is: Access is denied.
Please work with your domain administrator to ensure that:
The cluster identity ‘IBDMMDBCLS${}^{\prime }hasCreateComputerObjectspermissions.Bydefaultallcomputerobjectsarecreatedinthesamecontainerastheclusteridentit{y}^{\prime }IBDMMDBCLS$’.
The quota for computer objects has not been reached.
If there is an existing computer object, verify the Cluster Identity ‘IBDMMDBCLS$’ has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool.
官方文檔的解釋https://docs.microsoft.com/en-us/archive/blogs/psssql/error-during-installation-of-an-sql-server-failover-cluster-instance
The common cause of the Network Name resource failure is insufficient permissions. More specifically, the permission “Create Computer Objects” has not been granted to the Cluster Name Object(CNO).
When the SQL Server Network Name is first brought online during the FCI installation process, the CNO identity is used to create the VCO(as long as the VCO doesn’t already exist). If the required permissions are not granted to the CNO, the creation of the VCO will fail and so will your SQL Server FCI installation.

翻譯：Network Name資源失敗的常見原因是權限不足。更具體地說，“創建計算機對象”的權限還沒有授予集群名稱對象(CNO)。
在FCI安裝過程中，當SQL Server Network Name首次上線時，使用CNO標識創建VCO(只要VCO還不存在)。如果沒有將所需的權限授予CNO, VCO的創建將失敗，SQL Server FCI安裝也將失敗。
Cluster Name object (CNO) 即WFC的名稱IBDMMDBCLS
Virtual Computer Object (VCO)，即AG listener的名稱IBDMMDBLS
解決方法：在域控環境找到IBDMMDBCLS用戶(非報錯信息中的IBDMMDBCLS$，其實這個$在域控中是不存在的)，給他授權full control或把它添加到有full control的組，之后再在AG里面創建AG listener不再報錯，AG listener創建成功后，可以在域控移除IBDMMDBCLS用戶用戶的權限，不影響已經已有的WFC和AG listener
25、如果可用性組顯示resolving，它下面的某個副本也顯示resolving，重啟服務器也無法解決這個問題時，使用Get-ClusterResource命令查看WFC下面哪個資源failed，也右鍵WFC選擇validate cluster再選擇view validation report查看WFC故障明細，如果短時間內實在無法解決，如下兩種方法都可以讓數據庫可用
25.1、禁用cluster，右鍵WFC選擇shut down cluster把cluster禁用，這樣數據庫的AG就中斷了，就可以把數據庫AG的主節點當成單節點來使用，不過這樣做的話AG從節點就無法做任何用途，最后還得重建AG才能用上AG的從節點
25.2、重建AG，首先在數據庫實例層面刪除AG，然后在操作系統的WFC中cluster可以看到role AG已經消失了，AG中的所有節點中的數據庫都變成單節點了，主節點數據庫是讀寫狀態后面沒有syncrihzoned狀態，從節點數據庫后面狀態從syncrihzoning變成restoring了

Always on的備份

問題：關于日志備份，我們都知道事物日志備份會截斷日志鏈，假如我在任意副本上執行了日志備份，那么其他副本的日志是否也會一起截斷？
答案：是的，一個副本執行日志備份，其他副本會自動截斷，只要主節點和輔助節點直接正常通信，不管怎么設置，日志都是可以備份的，可以在主節點備份，也可以在輔助節點備份，只是不能同時備份，不管在哪個節點備份，都會截斷所有節點的日志
其實只要在“備份首選項”（可用性組，右鍵，屬性，）指定的數據庫實例上“備份事務日志”即可將事務日志備份并截斷

AG的主副本備份執行如下，都正常
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db1_alwayson1_full.bak’
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db1_alwayson1_diff.bak’ WITH DIFFERENTIAL
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db1_alwayson1_log2.bak’

AG輔助副本上支持的備份類型
1、BACKUP DATABASE ：在輔助副僅支持數據庫、文件或文件組的僅復制完整備份。請注意，僅復制備份不影響日志鏈，也不清除差異位圖。
2、輔助副本不支持差異備份(不過實驗發現加了with differential,copy_only的話也可以備份)
3、BACKUP LOG 僅支持常規日志備份（輔助副本上的日志備份不支持 COPY_ONLY 選項）。
4、若要備份輔助數據庫，輔助副本必須能夠與主副本進行通信，并且狀態必須為 SYNCHRONIZED 或 SYNCHRONIZING。否則會報錯Cannot backup from a HADRON secondary because it is not in Synchronizing or Synchronized state.
注意:在分布式可用性組中，可以對與活動主要副本相同的可用性組中的次要副本執行備份，或對任何次要可用性組的主要副本執行備份。 無法對次要可用性組中的次要副本執行備份，因為次要副本僅與其可用性組中的主要副本通信。 僅直接與全局主要副本通信的副本才能執行備份操作。

AG的輔助副本備份執行如下，報錯(無法備份數據庫)
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full.bak’
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_diff.bak’ WITH DIFFERENTIAL
出現如下報錯：
This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

AG的輔助副本備份執行如下，正常備份(可以備份日志)
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log.bak’

AG的輔助副本備份執行如下，報錯(日志備份不支持COPY_ONLY)
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log.bak’ with copy_only

AG的輔助副本備份執行如下，都正常(數據庫備份只支持copy_only)
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full.bak’ with copy_only
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_diff.bak’ WITH DIFFERENTIAL ,copy_only
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log2.bak’

實例–Always On 高可用性–可用性組–可用性組名–右鍵–屬性—備份首選項

優先輔助副本(默認選項)
指定備份應在輔助副本上發生，沒有聯機可用的輔助副本時，備份應在主副本上發生。

僅輔助副本
指定備份只發生在輔助副本，沒有聯機可用的輔助副本時，則備份不會發生。

主副本
指定備份應該始終在主副本上發生。

任意副本
指定您希望在選擇要執行備份的副本時備份作業將忽略可用性副本的角色。此選項下面還有一個副本備份優先級的設置，1位最低，100為最高，默認是情況下主副本和輔助副本都是50。

以上，四種選項的結果，也可以通過sys.fn_hadr_backup_is_preferred_replica函數查詢出來，如果當前數據庫是首選備份副本，則返回 1。
比如SELECT sys.fn_hadr_backup_is_preferred_replica (‘testdb’)結果為1，則此實例的testdb是可用性組中的首選備份副本

總結

以上是生活随笔為你收集整理的sqlserver关于always on的总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。