複寫、變更追蹤與異動資料擷取 - Always On 可用性群組
適用於:SQL Server
Always On 可用性群組支援 SQL Server 複寫、異動資料擷取 (CDC) 及變更追蹤 (CT)。 Always On 可用性群組有助於提供高可用性和其他資料庫復原功能。
可用性群組的複寫概觀
發行者重新導向
當發行的資料庫能夠感知 Always On 可用性群組時,提供發行資料庫其代理程式存取權的散發者就會使用 redirected_publishers 項目來設定。 這些項目會重新導向原本設定的發行者/資料庫配對,並利用可用性群組接聽程式名稱來連接到發行者和發行資料庫。 透過可用性群組接聽程式名稱所建立的連接將會在容錯移轉時失敗。 在容錯移轉之後,當複寫代理程式重新啟動時,連接將自動重新導向至新的主要複本。
在可用性群組中,次要資料庫不能是發行者。 只有在異動複寫與 Always On 可用性群組結合時,才支援重新發行。
如果發行的資料庫是可用性群組的成員,而且發行者已重新導向,它就必須重新導向至與可用性群組相關聯的可用性群組接聽程式名稱。 它可能不會重新導向至明確節點。
注意
在容錯移轉到次要複本之後,複寫監視器就無法調整 SQL Server 發行執行個體的名稱,且會繼續在原始主要 SQL Server 執行個體名稱之下顯示複寫資訊。 在容錯移轉之後,便無法使用複寫監視器輸入追蹤 Token,但是可以在複寫監視器中看到在新發行者端使用 Transact-SQL 輸入的追蹤 Token。
支援可用性群組的複寫代理程式一般變更
已修改三個複寫代理程式以支援 Always On 可用性群組。 記錄讀取器、快照集和合併代理程式已修改成查詢重新導向發行者的散發資料庫,並且使用傳回的可用性群組接聽程式名稱來連接到資料庫發行者 (如果已宣告重新導向發行者的話)。
根據預設,當代理程式查詢散發者以判斷原始發行者是否已重新導向時,會驗證重新導向目前目標的適用性,然後才將重新導向的主機傳回至代理程式。 這是建議的行為。 不過,如果代理程式啟動很頻繁,則與驗證預存程序相關的額外負荷成本可能太高。 新命令列參數 BypassPublisherValidation 已新增至記錄讀取器、快照集和合併代理程式。 使用此參數時,重新導向的主機會立即傳回至代理程式,而略過驗證預存程序的執行。
從驗證預存程序傳回的失敗會記錄在代理程式記錄檔中。 嚴重性大於或等於 16 的這些錯誤會導致代理程式終止。 某些重試功能已內建到代理程式,以處理在容錯移轉至新主要複本時預期的已發行資料庫中斷連接。
記錄讀取器代理程式修改
記錄讀取器代理程式有下列變更。
複寫的資料庫一致性
當發行的資料庫是可用性群組的成員時,記錄讀取器預設不會處理所有可用性群組次要複本上尚未強行寫入的記錄檔記錄。 這樣可確保容錯移轉時,所有複寫至訂閱者的資料列也會存在新的主要複本上。
當發行者只有兩個可用性複本 (一個主要和一個次要) 且發生容錯移轉時,原始的主要複本會保持離線,因為在所有次要資料庫恢復連線或發生錯誤的次要複本從可用性群組中移除之前,記錄讀取器不會向前移動。 現在針對次要資料庫執行的記錄讀者器將不會繼續前進,因為 Always On 無法強行對任何次要資料庫進行任何變更。 若要讓記錄讀取器繼續前進且仍然擁有災害復原的能力,請使用 ALTER AVAILABITY GROUP <group_name> REMOVE REPLICA 從可用性群組中移除原始主要複本。 然後將新的次要複本加入至可用性群組。
追蹤旗標 1448
追蹤旗標 1448 可讓複寫記錄讀取器向前移動,即使非同步次要複本尚未認可收到變更也一樣。 即使在已啟用這個追蹤旗標的情況下,記錄讀取器也一律會等候同步次要複本 (它們可能會變成非同步認可模式,如這裡所述,因此記錄讀取器可以向前移動。)。 記錄讀取器不會超過同步次要複本的最小認可。 這個追蹤旗標會套用至 SQL Server 執行個體,而不只套用至可用性群組、可用性資料庫或記錄讀取器執行個體。 這個追蹤旗標會立即生效,不必重新啟動。 您可以事先或在非同步次要複本失敗時啟動它。
支援可用性群組的預存程序
sp_redirect_publisher
預存程序 sp_redirect_publisher 可用來指定現有發行者/資料庫配對的重新導向發行者。 如果發行者資料庫屬於可用性群組,重新導向發行者就是可用性群組接聽程式名稱。
sp_get_redirected_publisher
預存程序 sp_get_redirected_publisher 可由複寫代理程式用來查詢散發者,以便判斷發行者/資料庫配對是否具有定義的重新導向發行者。 此預存程序有兩種目的。 首先,它可讓代理程式判斷原始發行者是否已經重新導向。 其次,它也可以在散發者端起始驗證預存程序 (sp_validate_redirected_publisher),以便驗證重新導向的目標節點是否適合作為具名資料庫的發行者。
若要執行此預存程序,呼叫端必須是 系統管理員 伺服器角色的成員、散發資料庫的 db_owner 資料庫角色,或是與發行者資料庫相關聯之定義發行集的 發行集存取清單 的成員。
sp_validate_redirected_publisher
此預存程序會嘗試驗證目前的發行者是否能夠裝載發行的資料庫。 您可以隨時呼叫此預存程序,以便確認發行之資料庫的目前主機是否能夠支援複寫。
sp_validate_replicate_hosts_as_publishers
雖然讓代理程式確保目前主要複本能夠作為發行者資料庫的複寫發行者運作已經很有用,不過還是需要一項更全面的驗證功能,才能確立 AlwaysOn 可用性資料庫上整個複寫拓撲的有效性。 預存程序 sp_validate_replica_hosts_as_publishers 就是為了滿足這項需求所設計。
此預存程序一律以手動方式執行。 呼叫端必須是散發者端的系統管理員 ( sysadmin )、散發資料庫的 dbowner 或是發行者資料庫中發行集之 發行集存取清單 的成員。 此外,對於所有可用性複本主機而言,呼叫端的登入必須是有效的登入,而且擁有與發行者資料庫相關聯之可用性資料庫的選取權限。
異動資料擷取
啟用異動資料擷取 (CDC) 的資料庫能夠使用 Always On 可用性群組,以便確保資料庫在發生失敗時維持可用狀態,且資料庫資料表的變更會繼續受到監視並儲放在 CDC 變更資料表中。 設定 CDC 和 Always On 可用性群組的順序並不重要。 啟用 CDC 的資料庫可以新增至 Always On 可用性群組中,且可以啟用本身為 Always On 可用性群組成員之資料庫的 CDC。 不過,在這兩種情況下,CDC 組態一律在目前或預期的主要複本上執行。 CDC 會使用記錄讀取器代理程式,而且其限制與本主題稍早的< 記錄讀取器代理程式修改 >一節中所述的限制相同。
在有異動資料擷取但沒有複寫的情況下,收集變更
如果資料庫啟用了 CDC,但是沒有啟用複寫,用來從記錄中收集變更並將變更儲放在 CDC 變更資料表中的擷取處理序就會在 CDC 主機上當做它自己的 SQL 代理程式作業執行。
若要在容錯移轉之後繼續收集變更,您必須在新的主要複本上執行預存程序 sp_cdc_add_job ,以便建立本機擷取作業。
下列範例會建立擷取作業。
EXEC sys.sp_cdc_add_job @job_type = 'capture';
在有異動資料擷取且有複寫的情況下,收集變更
如果同時啟用了資料庫的 CDC 和複寫,記錄讀取器就會處理 CDC 變更資料表的母體擴展。 在此情況中,複寫用來使用 Always On 可用性群組的技術將可確保系統在容錯移轉之後繼續從記錄中收集變更並儲放在 CDC 變更資料表中。 在此組態中,不需要為 CDC 執行更多動作,就可確保變更資料表會擴展。
異動資料擷取清除
為了確保新的主要資料庫會進行適當的清除,一定要建立本機清除作業。 下列範例會建立清除作業。
EXEC sys.sp_cdc_add_job @job_type = 'cleanup';
注意
在容錯移轉之後,您應在新的主要複本上建立作業。 當本機資料庫變成次要資料庫時,應停用在舊主要資料庫上執行的 CDC 作業。 如果複本再次變成主要複本,您必須重新啟用複本的 CDC 作業。 若要停用和啟用作業,請使用 sp_update_job (Transact-SQL) 的 @enabled 選項。 如需建立 CDC 作業的詳細資訊,請參閱 sys.sp_cdc_add_job (Transact-SQL)。
將 CDC 角色加入 AlwaysOn 主要資料庫複本中
當資料表啟用 CDC 時,有可能將資料庫角色與擷取執行個體建立關聯。 如果指定了角色,希望使用 CDC 資料表值函式來存取資料表變更的使用者必須不只有追蹤資料表資料行的選取存取權,也必須是具名角色的成員。 如果指定的角色尚未存在,則會建立角色。 當資料庫角色自動加入 AlwaysOn 主要資料庫中時,這些角色也會傳播至可用性群組的次要資料庫。
存取 CDC 變更資料的用戶端應用程式和 AlwaysOn
使用資料表值函式 (TVF) 或連結的伺服器存取變更資料表資料的用戶端應用程式,也需要在容錯移轉後找出適當 CDC 主機的功能。 可用性群組接聽程式名稱是 Always On 可用性群組所提供的機制,這項機制會以透明的方式允許連線將目標重定至不同主機。 一旦可用性群組接聽程式名稱與可用性群組產生關聯之後,它就可用於 TCP 連接字串中。 透過可用性群組接聽程式名稱支援兩個不同的連接案例。
一個確保連接要求一律導向至目前的主要複本。
一個確保連接要求會導向至唯讀的次要複本。
如果用來找出唯讀的次要複本,還必須為可用性群組定義唯讀的路由清單。 如需可讀取次要複本之路由存取的詳細資訊,請參閱本節稍後的 若要將可用性複本設定為唯讀路由。
注意
建立可用性群組接聽程式名稱以及用戶端應用程式用它來存取可用性群組資料庫複本時,都會發生一些相關聯的傳播延遲。
請使用下列查詢來判斷是否已針對裝載 CDC 資料庫的可用性群組定義了可用性群組接聽程式名稱。 如果已建立可用性群組接聽程式名稱,查詢會傳回它。
SELECT dns_name FROM sys.availability_group_listeners AS l INNER JOIN sys.availability_databases_cluster AS d ON l.group_id = d.group_id WHERE d.database_name = N'MyCDCDB';
將查詢負載重新導向至可讀取次要複本
雖然在許多情況下用戶端應用程式一律會要連線到目前的主要複本,但這不是使用 Always On 可用性群組的唯一方法。 如果可用性群組設定為支援可讀取的次要複本,則也可以從次要節點收集變更資料。
已設定可用性群組時,與 SECONDARY_ROLE 關聯的 ALLOW_CONNECTIONS 屬性會用來指定支援的次要存取類型。 如果設定為 ALL,則會允許次要的所有連線,但只有需要唯讀存取的連線會成功。 如果設定為 READ_ONLY,則需要在建立次要資料庫的連接時指定唯讀意圖,連接才會成功。 如需詳細資訊,請參閱設定可用性複本上的唯讀存取 (SQL Server)。
您可以使用下列查詢,以判斷是否需要唯讀意圖以連接到可讀取次要複本。
SELECT g.name AS AG, replica_server_name, secondary_role_allow_connections_desc FROM sys.availability_replicas AS r JOIN sys.availability_groups AS g ON r.group_id = g.group_id WHERE g.name = N'MY_AG_NAME';
可用性群組接聽程式名稱或明確節點名稱都可用於找出次要複本。 如果使用可用性群組接聽程式名稱,則存取會導向至任何合適的次要複本。
當 sp_addlinkedserver 用於建立連結的伺服器以存取次要複本時, @datasrc 參數會用於可用性群組接聽程式名稱或明確伺服器名稱,而 @provstr 參數會用於指定唯讀意圖。
EXEC sp_addlinkedserver @server = N'linked_svr', @srvproduct=N'SqlServer', @provider=N'MSOLEDBSQL', @datasrc=N'AG_Listener_Name', @provstr=N'ApplicationIntent=ReadOnly', @catalog=N'MY_DB_NAME';
CDC 變更資料的用戶端存取和網域登入
一般而言,若要讓用戶端存取位於 AlwaysOn 可用性群組之成員資料庫的變更資料,您應該使用網域登入。 為確保在容錯移轉後持續存取變更資料,網域使用者需要所有支援可用性群組複本之主機的存取權限。 如果將資料庫使用者加入至主要複本的資料庫,而此使用者已與網域登入相關聯,則此資料庫使用者會傳播至次要資料庫並繼續與指定的網域登入相關聯。 如果新資料庫使用者與 SQL Server 驗證登入相關聯,則次要資料庫的使用者會傳播但沒有登入。 雖然相關 SQL Server 驗證登入可用來存取原本定義資料庫使用者所在主要資料庫的變更資料,但該節點是唯一可存取的節點。 此 SQL Server 驗證登入無法存取任何次要資料庫的資料,也無法存取資料庫使用者定義所在原始資料庫以外任何新主要資料庫的資料。
停用異動資料擷取
如果您需要在屬於 Always On 可用性群組的資料庫上停用異動資料擷取 (CDC),且您使用的是 SQL Server 2016 SP2 或更新版本,則不需要執行任何額外的步驟來自動截斷記錄。 如果您使用的是 SQL Server 2016 SP2 之前的版本,而且在屬於可用性群組的資料庫上停用 CDC,則您將需實作下列其中一個步驟,以防止在停用 CDC 之後封鎖記錄截斷:- 重新啟動每個次要複本執行個體上的 SQL Server 服務。
- 從可用性群組的所有次要複本執行個體中移除資料庫,接著使用自動或手動植入,將它新增回可用性群組複本執行個體。
變更追蹤
啟用變更追蹤 (CT) 的資料庫可以屬於 AlwaysOn 可用性群組的一部分。 不需要任何其他組態。 使用 CDC 資料表值函式 (TVF) 存取變更資料表資料的變更追蹤用戶端應用程式,需要在容錯移轉後找出主要複本的功能。 如果用戶端應用程式透過可用性群組接聽程式名稱進行連接,連接要求一律會適當導向至目前的主要複本。
注意
變更追蹤資料必須一律從主要複本取得。 嘗試存取次要複本的變更資料會導致下列錯誤:
訊息 22117,層級 16,狀態 1,行 1
次要複本的成員資料庫 (即次要資料庫) 不支援變更追蹤。 作為在主要複本上執行變更追蹤查詢的替代方法,您可以從次要複本建立 AG 資料庫的資料庫快照集,然後使用該快照集來查詢變更資料。 資料庫快照集是 SQL Server 資料庫 (來源資料庫) 的唯讀靜態檢視,因此資料庫快照集內的變更追蹤資料將會是從次要複本在 AG 資料庫上擷取快照集時的時間。
注意
當啟用了變更追蹤的資料庫發生容錯移轉時,新主要複本上的復原時間可能比平常更長,因為變更追蹤需要完全重新啟動資料庫。
使用複寫的必要條件、限制和考量
本節描述使用 Always On 可用性群組來部署複寫的考量,包括先決條件、限制和建議。
必要條件
當使用異動複寫,且發行集資料庫是在可用性群組時,發行者和散發者都必須至少執行 SQL Server 2012 (11.x)。 訂閱者可以使用較低層級的 SQL Server。
當使用合併式複寫,而且發行集資料庫是在可用性群組時:
發送訂閱:發行者和散發者都必須至少執行 SQL Server 2012 (11.x)。
提取訂閱:發行者、散發者和訂閱者資料庫必須至少是在 SQL Server 2012 (11.x) 上。 這是因為訂閱者的合併代理程式必須知道可用性群組如何容錯移轉到次要複本。
發行者執行個體必須滿足參與 AlwaysOn 可用性群組所需的所有必要條件。 如需詳細資訊,請參閱 Always On 可用性群組的先決條件、限制和建議 (SQL Server)。
限制
Always On 可用性群組支援的複寫組合:
複寫 | 發行者 | 散發者1 | 用戶 |
---|---|---|---|
異動 | 是 注意:不包含對雙向和相互異動複寫的支援。 |
是 | Yes |
點對點2 | 是 | 是3 | 是 |
合併式 | 是 | 無 | 否 |
快照式 | 是 | 無 | Yes |
可更新訂閱 - 適用於異動複寫 | No | 無 | No |
1 散發者資料庫不支援與資料庫鏡像搭配使用。
2 需要 SQL Server 2019 CU 13 或更新版本。
3 需要 SQL Server 2019 CU 17 或更新版本。
考量
散發資料庫不支援與資料庫鏡像搭配使用,但支援在受到特定限制的情況下與 Always On 可用性群組搭配使用,請參閱設定散發可用性群組。 複寫組態會結合至設定散發者所在的 SQL Server 執行個體。因此,無法鏡像或複寫散發資料庫。 您也可以使用 SQL Server 容錯移轉叢集來為散發者提供高可用性。 如需詳細資訊,請參閱 AlwaysOn 容錯移轉叢集執行個體 (SQL Server)。
雖然支援訂閱者容錯移轉至次要資料庫,不過這是合併式複寫訂閱者的手動程序。 此程序基本上與用來容錯移轉鏡像訂閱者資料庫的方法完全相同。 異動複寫訂閱者不需要特殊處理就能參與 Always On 可用性群組。 訂閱者必須執行 SQL Server 2012 (11.x) 或更新版本,才能參與可用性群組。 如需詳細資訊,請參閱 複寫訂閱者及 AlwaysOn 可用性群組 (SQL Server)
存在於資料庫之外的中繼資料和物件不會傳播到次要複本,包括登入、作業、連結的伺服器。 如果您需要在容錯移轉後使用新主要資料庫上的中繼資料和物件,則必須手動加以複製。 如需詳細資訊,請參閱管理可用性群組之資料庫的登入及工作 (SQL Server)。
分散式可用性群組
發行者,或可用性群組中散發資料庫無法作為散發可用性群組的一部分來設定。 可用性群組中發行者資料庫和可用性群組中的散發資料庫都需要接聽程式端點,才能進行適當的設定和使用。 但是,您無法為分散式可用性群組設定接聽程式端點。
相關工作
複寫
變更資料擷取
Change tracking
另請參閱
複寫訂閱者及 AlwaysOn 可用性群組 (SQL Server)
AlwaysOn 可用性群組的必要條件、限制和建議 (SQL Server)
AlwaysOn 可用性群組概觀 (SQL Server)
AlwaysOn 可用性群組:互通性 (SQL Server)
AlwaysOn 容錯移轉叢集執行個體 (SQL Server)
關於異動資料擷取 (SQL Server)
關於變更追蹤 (SQL Server)
SQL Server 複寫
追蹤資料變更 (SQL Server)
sys.sp_cdc_add_job (Transact-SQL)