共用方式為

複寫、變更追蹤、異動數據擷取和 AlwaysOn 可用性群組 （SQL Server）

AlwaysOn 可用性群組支援 SQL Server 複寫、異動數據擷取（CDC）和變更追蹤（CT）。 AlwaysOn 可用性群組可協助提供高可用性和其他資料庫復原功能。

AlwaysOn 可用性群組上的復寫概觀

發行者重新導向

當發行的資料庫知道 AlwaysOn 可用性群組時，提供發行資料庫的代理程式存取權的散發者會設定redirected_publishers專案。 這些項目會重新導向原本設定的發行者/資料庫配對，並利用可用性群組接聽程式名稱來連接到發行者和發行資料庫。 透過可用性群組接聽程式名稱所建立的連接將會在容錯移轉時失敗。 在容錯移轉之後，當複寫代理程式重新啟動時，連接將自動重新導向至新的主要複本。

在AlwaysOn可用性群組中，輔助資料庫不能是發行者。 當復寫與 AlwaysOn 可用性群組結合時，不支援重新發佈。

如果發行的資料庫是可用性群組的成員，而且發行者已重新導向，它就必須重新導向至與可用性群組相關聯的可用性群組接聽程式名稱。 它可能不會重新導向至明確節點。

注意

在容錯移轉到次要複本之後，複寫監視器就無法調整 SQL Server 發行執行個體的名稱，且會繼續在原始主要 SQL Server 執行個體名稱之下顯示複寫資訊。 在容錯移轉之後，便無法使用複寫監視器輸入追蹤 Token，但是可以在複寫監視器中看到在新發行者端使用 Transact-SQL 輸入的追蹤 Token。

復寫代理程式的一般變更以支援 AlwaysOn 可用性群組

已修改三個復寫代理程式以支援 AlwaysOn 可用性群組。 記錄讀取器、快照集和合併代理程式已修改成查詢重新導向發行者的散發資料庫，並且使用傳回的可用性群組接聽程式名稱來連接到資料庫發行者 (如果已宣告重新導向發行者的話)。

根據預設，當代理程式查詢散發者以判斷原始發行者是否已重新導向時，會驗證重新導向目前目標的適用性，然後才將重新導向的主機傳回至代理程式。 這是建議的行為。 不過，如果代理程式啟動經常發生，與驗證預存程式相關聯的額外負荷可能會被視為太昂貴。 已將新的命令行參數 BypassPublisherValidation 新增至 Logreader、Snapshot 和 Merge 代理程式。 使用此參數時，重新導向的主機會立即傳回至代理程式，而略過驗證預存程序的執行。

從驗證預存程序傳回的失敗會記錄在代理程式記錄檔中。 嚴重性大於或等於 16 的這些錯誤會導致代理程式終止。 某些重試功能已內建到代理程式，以處理在容錯移轉至新主要複本時預期的已發行資料庫中斷連接。

記錄讀取器代理程式修改

Logreader 代理程式有下列變更。

  • 複寫的資料庫一致性

    當已發佈的資料庫是 AlwaysOn 可用性群組的成員時，記錄讀取器預設不會處理所有可用性群組次要複本尚未強化的記錄檔記錄。 這可確保在故障轉移時，所有復寫到訂閱者的數據列也會出現在新的主要複本上。

    當發行者只有兩個 AlwaysOn 可用性複本（一個主要和一個次要複本）和故障轉移發生時，原始的主要複本會保持關閉，因為 logreader 不會向前移動，直到所有輔助資料庫恢復上線，或直到失敗的次要複本從可用性群組中移除為止。 現在針對輔助資料庫執行的logreader將不會繼續執行，因為AlwaysOn無法強化任何輔助資料庫的變更。 若要讓 logreader 繼續進行，但仍具有災害復原容量，請使用 ALTER AVAILABITY GROUP <group_name> REMOVE REPLICA，從可用性群組中移除原始的主要複本。 然後將新的次要複本加入至可用性群組。

  • 追蹤旗標 1448

    追蹤旗標 1448 可讓複寫記錄讀取器向前移動，即使非同步次要複本尚未認可收到變更也一樣。 即使啟用此追蹤旗標，記錄讀取器一律會等候同步次要複本。 記錄讀取器不會超過同步次要複本的最小認可。 這個追蹤旗標會套用至 SQL Server 執行個體，而不只套用至可用性群組、可用性資料庫或記錄讀取器執行個體。 這個追蹤旗標會立即生效，不必重新啟動。 您可以事先或在非同步次要複本失敗時啟動它。

支援 AlwaysOn 的預存程式

  • 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）能夠運用 AlwaysOn 可用性群組，以確保資料庫在發生失敗時仍保持可用，而且資料庫數據表的變更會繼續監視並儲存在 CDC 變更數據表中。 設定 CDC 和 AlwaysOn 可用性群組的順序並不重要。 已啟用 CDC 的資料庫可以新增至 AlwaysOn 可用性群組，而且可以針對 CDC 啟用 AlwaysOn 可用性群組成員的資料庫。 不過，在這兩種情況下，CDC 組態一律在目前或預期的主要複本上執行。 CDC 會使用記錄讀取器代理程式，而且其限制與本主題稍早的＜ 記錄讀取器代理程式修改 ＞一節中所述的限制相同。

  • 在有異動資料擷取但沒有複寫的情況下，收集變更

    如果資料庫啟用了 CDC，但是沒有啟用複寫，用來從記錄中收集變更並將變更儲放在 CDC 變更資料表中的擷取處理序就會在 CDC 主機上當做它自己的 SQL 代理程式作業執行。

    若要在容錯移轉之後繼續收集變更，您必須在新的主要複本上執行預存程序 sp_cdc_add_job ，以便建立本機擷取作業。

    下列範例會建立擷取作業。

    EXEC sys.sp_cdc_add_job @job_type = 'capture';

  • 在有異動資料擷取且有複寫的情況下，收集變更

    如果同時啟用了資料庫的 CDC 和複寫，記錄讀取器就會處理 CDC 變更資料表的母體擴展。 在此情況下，復寫用來利用 AlwaysOn 可用性群組的技術可確保在故障轉移之後，從記錄檔中繼續收集變更，並儲存在 CDC 變更數據表中。 此設定中 CDC 不需要執行任何其他動作，以確保變更資料表已填入。

  • 異動資料擷取清除

    若要確保適當的清除發生在新的主資料庫，應該一律建立本機清除作業。 下列範例會建立清除作業。

    EXEC sys.sp_cdc_add_job @job_type = 'cleanup';

    注意

    在故障轉移之前，您應該在所有可能的故障轉移目標上建立作業，並將其標示為停用，直到主機上的可用性複本變成新的主要複本為止。 當本機資料庫變成輔助資料庫時，也應該停用在舊主資料庫上執行的 CDC 作業。 若要停用和啟用作業，請使用 sp_update_job (Transact-SQL) 的 @enabled 選項。 如需建立 CDC 作業的詳細資訊，請參閱 sys.sp_cdc_add_job (Transact-SQL)。

  • 將 CDC 角色新增至 AlwaysOn 主資料庫複本

    當資料表啟用 CDC 時，有可能將資料庫角色與擷取執行個體建立關聯。 如果指定了角色，希望使用 CDC 資料表值函式來存取資料表變更的使用者必須不只有追蹤資料表資料行的選取存取權，也必須是具名角色的成員。 如果指定的角色尚未存在，則會建立角色。 當資料庫角色自動新增至 AlwaysOn 主資料庫時，角色也會傳播至可用性群組的輔助資料庫。

  • 存取 CDC 變更資料的用戶端應用程式和 AlwaysOn

    使用資料表值函式 (TVF) 或連結的伺服器存取變更資料表資料的用戶端應用程式，也需要在容錯移轉後找出適當 CDC 主機的功能。 可用性群組接聽程式名稱是 AlwaysOn 可用性群組所提供的機制，可透明地允許將連線複位為不同的主機。 一旦可用性群組接聽程式名稱與可用性群組產生關聯之後，它就可用於 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';

  • 將查詢負載重新導向至可讀取次要複本

    雖然在許多情況下，用戶端應用程式一律會想要連線到目前的主要復本，而這不是利用AlwaysOn可用性群組的唯一方法。 如果可用性群組設定為支援可讀取的次要複本，則也可以從次要節點收集變更資料。

    已設定可用性群組時，與 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'SQLNCLI11',   
@datasrc=N'AG_Listener_Name',   
@provstr=N'ApplicationIntent=ReadOnly',   
@catalog=N'MY_DB_NAME';

  • CDC 變更資料的用戶端存取和網域登入

    一般而言，您應該使用網域登入來存取用戶端，以變更位於AlwaysOn可用性群組成員之資料庫中的數據。 若要確保故障轉移後繼續存取變更數據，網域使用者將需要支援可用性群組複本之所有主機上的訪問許可權。 如果將資料庫使用者加入至主要複本的資料庫，而此使用者已與網域登入相關聯，則此資料庫使用者會傳播至次要資料庫並繼續與指定的網域登入相關聯。 如果新資料庫使用者與 SQL Server 驗證登入相關聯，則次要資料庫的使用者會傳播但沒有登入。 雖然相關 SQL Server 驗證登入可用來存取原本定義資料庫使用者所在主要資料庫的變更資料，但該節點是唯一可存取的節點。 此 SQL Server 驗證登入無法存取任何次要資料庫的資料，也無法存取資料庫使用者定義所在原始資料庫以外任何新主要資料庫的資料。

變更追蹤

啟用變更追蹤的資料庫可以是 AlwaysOn 可用性群組的一部分。 不需要任何其他設定。 使用 CDC 資料表值函式 (TVF) 存取變更資料表資料的變更追蹤用戶端應用程式，需要在容錯移轉後找出主要複本的功能。 如果用戶端應用程式透過可用性群組接聽程式名稱進行連接，連接要求一律會適當導向至目前的主要複本。

注意

變更追蹤資料必須一律從主要複本取得。 嘗試存取次要複本的變更資料會導致下列錯誤：

訊息 22117，層級 16，狀態 1，行 1

次要複本的成員資料庫 (即次要資料庫) 不支援變更追蹤。 在主要復本中的資料庫上執行變更追蹤查詢。

使用複寫的必要條件、限制和考量

本節說明使用 AlwaysOn 可用性群組部署複寫的考慮，包括必要條件、限制和建議。

必要條件

  • 使用事務複製和發行資料庫時，發行者與散發者都必須至少執行 SQL Server 2012 的可用性群組。 訂閱者可以使用較低層級的 SQL Server。

  • 當使用合併式複寫，而且發行集資料庫是在可用性群組時：

    • 發送訂閱：發行者和散發者必須至少執行 SQL Server 2012。

    • 提取訂閱：發行者、散發者和訂閱者資料庫至少必須位於 SQL Server 2012 上。 這是因為訂閱者的合併代理程式必須知道可用性群組如何容錯移轉到次要複本。

  • 不支援將散發資料庫放在可用性群組上。

  • 發行者實例滿足參與 AlwaysOn 可用性群組所需的所有必要條件。 如需詳細資訊，請參閱 AlwaysOn 可用性群組的必要條件、限制和建議（SQL Server）。

限制

AlwaysOn 可用性群組上支持的復寫組合：
發行者 散發者3 訂用帳戶
異動 是1 否 是2
P2P 否 否 否
合併式 是 否 是2
快照式 是 否 是2

1 不包含雙向和相互事務複製的支援。

2 故障轉移至複本資料庫是手動程式。 未提供自動故障轉移。

3 不支援散發者資料庫與 AlwaysOn 可用性群組或資料庫鏡像搭配使用。

考量

  • 不支援散發資料庫與 AlwaysOn 可用性群組或資料庫鏡像搭配使用。 複寫組態會結合至設定散發者所在的 SQL Server 執行個體。因此，無法鏡像或複寫散發資料庫。 若要為散發者提供高可用性，請使用 SQL Server 故障轉移叢集。 如需詳細資訊，請參閱 AlwaysOn 容錯移轉叢集執行個體 (SQL Server)。

  • 訂閱者故障轉移至輔助資料庫，雖然支援，但相當複雜。 此程序基本上與用來容錯移轉鏡像訂閱者資料庫的方法完全相同。 訂閱者必須執行 SQL Server 2012 或更新版本，才能參與可用性群組。

  • 存在於資料庫之外的中繼資料和物件不會傳播到次要複本，包括登入、作業、連結的伺服器。 如果您需要在容錯移轉後使用新主要資料庫上的中繼資料和物件，則必須手動加以複製。 如需詳細資訊，請參閱管理可用性群組之資料庫的登入及工作 (SQL Server)。

相關工作

複寫

變更資料擷取

變更追蹤

另請參閱

複寫訂閱者與 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）

  • Last updated on