sqlserver關於always on的總結

官方文件

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的搭建

網上手把手的教程網址

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，但是A1本機所有的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正常了

23、Always on的輔助節點的資料庫wdb1配置了logshipping，這個wdb1對應的LSBackup作業一直執行正常，突然之間報錯，報錯資訊如下
2020-09-08 09:15:05.55    First attempt to backup database 'wdb1' to file '\\log.hbank.com\WONDB\LOG\wdb1_20200908161504.trn' failed because Log backup for database "wdb1" on a secondary replica failed because the last backup LSN (0x00752347:00036eb5:0001) from the primary database is greater than the current local redo LSN (0x00752344:011b9f14:0176). No log records need to be backed up at this time. Retry the log-backup operation later.
解決方法：只能等Always on的主節點的日誌都在輔助節點應用完畢，這個時候Always on的輔助節點的資料庫wdb1的LSBackup作業才會自動恢復正常

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$' has Create Computer Objects permissions. By default all computer objects are created in the same container as the cluster identity '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是可用性組中的首選備份副本