レプリケーション、変更の追跡、変更データ キャプチャ - Always On 可用性グループ

  • [アーティクル]

適用対象: SQL Server

SQL ServerAlways On 可用性グループのレプリケーション、変更データ キャプチャ (CDC)、および変更の追跡 (CT) がサポートされています。 Always On 可用性グループ は、高可用性とその他のデータベース復旧機能を提供するのに役立ちます。

可用性グループによるレプリケーションの概要

パブリッシャー リダイレクト

パブリッシュされたデータベースが Always On 可用性グループに対応している場合、パブリッシング データベースへのエージェント アクセス権を提供するディストリビューターは、redirected_publishers エントリで構成されます。 これらのエントリは、パブリッシャーとパブリッシング データベースへの接続に可用性グループ リスナー名を使用して、最初に構成されていたパブリッシャー/データベース ペアをリダイレクトします。 可用性グループ リスナー名を介して確立された接続は、フェールオーバーに失敗します。 フェールオーバー後にレプリケーション エージェントを再起動すると、接続は自動的に新しいプライマリにリダイレクトされます。

可用性グループでセカンダリ データベースをパブリッシャーにすることはできません。 トランザクション レプリケーションを Always On 可用性グループと組み合わせている場合にのみ、再パブリッシュがサポートされます。

パブリッシュされたデータベースが可用性グループのメンバーであり、パブリッシャーをリダイレクトする場合は、その可用性グループに関連付けられている可用性グループ リスナー名にリダイレクトする必要があります。 明示的なノードにリダイレクトさせることはできません。

Note

セカンダリ レプリカにフェールオーバーした後、レプリケーション モニターは SQL Server のパブリッシング インスタンスの名前を調整できないため、 SQL Serverの元のプライマリ インスタンスの名前を引き続き使ってレプリケーション情報が表示されます。 フェールオーバー後は、トレーサー トークンはレプリケーション モニターを使用して入力できませんが、新しいパブリッシャーで Transact-SQL を使用して入力されたトレース トークンがレプリケーション モニターに表示されます。

可用性グループをサポートするためのレプリケーション エージェントへの一般的な変更

Always On 可用性グループをサポートするために、3 つのレプリケーション エージェントが変更されました。 ログ リーダー、スナップショット、およびマージ エージェントは、リダイレクトされたパブリッシャーについてディストリビューション データベースにクエリを実行し、リダイレクトされたパブリッシャーが宣言されていた場合は、返された可用性グループ リスナー名を使用してデータベース パブリッシャーに接続するように変更されました。

既定では、エージェントがディストリビューターにクエリを実行して、元のパブリッシャーがリダイレクトされたかどうかを判断する場合、リダイレクトされたホストがエージェントに戻る前に、現在のターゲットまたはリダイレクトの適合性が検証されます。 これは推奨される動作です。 ただし、エージェントの起動が頻繁に行われる場合、検証ストアド プロシージャに関連するオーバーヘッドのコストが高くなる可能性があります。 新しいコマンド ライン スイッチ BypassPublisherValidation が、ログ リーダー、スナップショット、およびマージ エージェントに追加されました。 スイッチが使用される場合、リダイレクトされたパブリッシャーはエージェントに即時に戻り、検証ストアド プロシージャの実行が省略されます。

検証ストアド プロシージャから返されるエラーは、エージェントの履歴ログに記録されます。 重大度が 16 以上のエラーが発生すると、エージェントが終了します。 新しいプライマリにフェールオーバーするときに、パブリッシュされたデータベースからの予期される切断を処理するために、いくつかの再試行機能がエージェントに組み込まれています。

ログ リーダー エージェントの変更

ログ リーダー エージェントでは次の点が変更されています。

  • レプリケートされたデータベースの一貫性

    パブリッシュされたデータベースが可用性グループのメンバーである場合、既定では、ログ リーダーはすべての可用性グループ セカンダリ レプリカでまだ書き込まれていないログ レコードを処理しません。 こうすることで、フェールオーバー時にサブスクライバーにレプリケートされるすべての行が、新しいプライマリにも存在することが保証されます。

    パブリッシャーに可用性レプリカが 2 つ (プライマリが 1 つとセカンダリが 1 つ) しかない場合にフェールオーバーが発生すると、すべてのセカンダリ データベースがオンラインに戻るか、エラーが発生したセカンダリ レプリカが可用性グループから削除されるまでログ リーダーが前へ進まないため、元のプライマリ レプリカはダウンしたままになります。 Always On がセカンダリ データベースに変更を書き込むことができないので、セカンダリ データベースに対して実行されているログ リーダーは前へ進みません。 ディザスター リカバリー機能を維持しながら、ログ リーダーが前へ進めるようにするには、ALTER AVAILABITY GROUP <group_name> REMOVE REPLICA を使用して、元のプライマリ レプリカを可用性グループから削除します。 その後、新しいセカンダリ レプリカを可用性グループに追加します。

  • トレース フラグ 1448

    トレース フラグ 1448 は、非同期セカンダリ レプリカで変更の受信が確認されていない場合でも、レプリケーション ログ リーダーが前へ進めるようにします。 このトレース フラグが有効な場合でも、ログ リーダーは常に同期セカンダリ レプリカを待機します (これらは、ここに記載されているように非同期コミット モードになる可能性があるため、ログ リーダーは前へ進むことができます)。 ログ リーダーは同期セカンダリ レプリカの最小 ack を超えることはありません。 このトレース フラグは、可用性グループ、可用性データベース、またはログ リーダー インスタンスだけでなく、 SQL Serverのインスタンスにも適用されます。 再起動しなくても、トレース フラグはすぐに有効になります。 このトレース フラグは、事前にアクティブにすることも、非同期セカンダリ レプリカで障害が発生したときにアクティブにすることもできます。

可用性グループをサポートするストアド プロシージャ

  • sp_redirect_publisher

    ストアド プロシージャ sp_redirect_publisher を使用すると、既存のパブリッシャー/データベース ペアのリダイレクトされたパブリッシャーを指定できます。 パブリッシャー データベースが可用性グループに属している場合、リダイレクトされたパブリッシャーは可用性グループ リスナー名です。

  • sp_get_redirected_publisher

    ストアド プロシージャ sp_get_redirected_publisher は、パブリッシャー/データベース ペアに定義済みのリダイレクトされたパブリッシャーがあるかどうかを判断するために、レプリケーション エージェントがディストリビューターに対してクエリを実行するときに使用されます。 このストアド プロシージャには、2 つの目的があります。 1 つ目は、元のパブリッシャーがリダイレクトされたかどうかをエージェントが判断できるようにすることです。 2 つ目は、リダイレクトの対象ノードが、指定されたデータベースのパブリッシャーとして適しているかどうかを検証する、ディストリビューターで実行される検証ストアド プロシージャ (sp_validate_redirected_publisher) を開始することです。

    このストアド プロシージャを実行するには、呼び出し元はディストリビューション データベースの sysadmin サーバー ロールおよび db_owner データベース ロールのメンバーであるか、パブリッシャー データベースと関連付けられている定義済みパブリケーションの パブリケーション アクセス リスト のメンバーである必要があります。

  • sp_validate_redirected_publisher

    このストアド プロシージャは、パブリッシュされたデータベースを現在のパブリッシャーがホストできることを検証しようとします。 パブリッシュされたデータベースの現在のホストがレプリケーションをサポートできることを確認するために、いつでも呼び出すことができます。

  • sp_validate_replicate_hosts_as_publishers

    現在のプライマリがパブリッシャー データベースのレプリケーション パブリッシャーとして機能できることを確認できるのはエージェントにとって便利ですが、Always On 可用性データベースのレプリケーション トポロジ全体の有効性を確立するには、より一般的な検証機能が必要です。 ストアド プロシージャ sp_validate_replica_hosts_as_publishers は、このニーズを満たすように設計されています。

    このストアド プロシージャは、常に手動で実行されます。 呼び出し元は、ディストリビューターでの sysadmin であるか、ディストリビューション データベースの dbowner であるか、またはパブリッシャー データベースのパブリケーションの パブリケーション アクセス リスト のメンバーである必要があります。 また、呼び出し元のログインは、すべての可用性レプリカ ホストに対して有効なログインであり、パブリッシャー データベースに関連付けられている可用性データベースに対する select 特権を持っている必要があります。

変更データ キャプチャ

障害が発生してもデータベースを引き続き使用できるだけでなく、データベース テーブルへの変更も引き続き監視され、CDC 変更テーブルに格納されることを保証するために、変更データ キャプチャ (CDC) が有効になっているデータベースで Always On 可用性グループ を使用できます。 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';

    Note

    フェールオーバー後に、新しいプライマリ レプリカでジョブを作成する必要があります。 ローカル データベースがセカンダリ データベースになったら、古いプライマリ データベースで実行されている CDC ジョブを無効にする必要があります。 この後、レプリカが再びプライマリになった場合は、レプリカで CDC ジョブを再度有効にする必要があります。 ジョブを無効/有効にするには、sp_update_job (Transact-SQL) の @enabled オプションを使用します。 CDC ジョブの作成の詳細については、「sys.sp_cdc_add_job (Transact-SQL)を参照してください。

  • Always On プライマリ データベース レプリカへの CDC ロールの追加

    CDC に対してテーブルを有効にした場合は、データベース ロールをキャプチャ インスタンスに関連付けることができます。 ロールが指定されている場合、CDC テーブル値関数を使用してテーブルの変更にアクセスするユーザーは、追跡されるテーブル列への選択アクセス権を持つだけでなく、名前付きロールのメンバーでもある必要があります。 指定したロールが存在しない場合は、ロールが作成されます。 Always On プライマリ データベースにデータベース ロールが自動的に追加されると、ロールは可用性グループのセカンダリ データベースにも反映されます。

  • CDC 変更データにアクセスするクライアント アプリケーションと Always On

    変更テーブル データにアクセスするためにテーブル値関数 (TVF) またはリンク サーバーを使用するクライアント アプリケーションには、フェールオーバー後に適切な CDC ホストを検索する機能も必要です。 可用性グループ リスナー名は、接続のターゲットを別のホストに透過的に再指定できるようにするために、 Always On 可用性グループ によって提供されるメカニズムです。 可用性グループに関連付けられた可用性グループ リスナー名は、TCP 接続文字列で使用できるようになります。 2 つの異なる接続シナリオが、可用性グループ リスナー名を通じてサポートされます。

    • 接続要求が常に現在のプライマリ レプリカに送られることを保証します。

    • 接続要求が読み取り専用セカンダリ レプリカに送られることを保証します。

    読み取り専用セカンダリ レプリカの検索にルーティング リストを使用する場合は、可用性グループの読み取り専用ルーティング リストも定義する必要があります。 読み取り可能セカンダリへのルーティングアクセスの詳細については、「 読み取り専用ルーティングの可用性レプリカを構成するには」を参照してください。

    Note

    可用性グループ データベース レプリカにアクセスするには、可用性グループ リスナー名の作成およびクライアント アプリケーションによる可用性グループ リスナー名の使用に関連するいくらかの伝達の遅延があります。

    次のクエリを使用して、可用性グループ リスナー名が 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 変更データとドメイン ログインへのクライアント アクセス

    一般に、Always On 可用性グループのメンバーであるデータベースに存在する変更データへのクライアント アクセスには、ドメイン ログインを使用する必要があります。 フェールオーバー後に変更データへの継続的なアクセスを保証するには、ドメイン ユーザーに、可用性グループ レプリカをサポートするすべてのホストに対するアクセス権限が必要です。 データベース ユーザーがプライマリ レプリカのデータベースに追加され、ユーザーがドメイン ログインに関連付けられている場合、データベース ユーザーはセカンダリ データベースに反映され、引き続き指定されたドメイン ログインに関連付けられます。 新しいデータベース ユーザーが SQL Server 認証ログインに関連付けられている場合、セカンダリ データベースのユーザーはログインなしで反映されます。 関連付けられた SQL Server 認証ログインを使用して、データベース ユーザーが最初に定義されたプライマリの変更データにアクセスできますが、ノードはアクセスが可能な唯一のノードです。 SQL Server 認証ログインは、セカンダリ データベースのデータにアクセスすることも、データベース ユーザーが定義された元のデータベース以外の新しいプライマリ データベースのデータにアクセスすることもできません。

  • 変更データ キャプチャの無効化
    Always On 可用性グループの一部であるデータベースで変更データ キャプチャ (CDC) を無効にする必要があり、かつ SQL Server 2016 SP2 以降を使用している場合、自動的なログ切り捨てに対して追加の手順を実行する必要はありません。 SQL Server 2016 SP2 より前のバージョンを使用しており、可用性グループの一部であるデータベースで CDC を無効にする場合、CDC を無効にした後にログ切り捨てがブロックされないように、次のいずれかの手順を実装する必要があります。

    • "すべての" セカンダリ レプリカ インスタンスで SQL Server サービスを再起動する。
    • 可用性グループのすべてのセカンダリ レプリカ インスタンスからデータベースを削除し、自動または手動シード処理を使用してそれぞれの可用性グループ レプリカ インスタンスにデータベースを追加し直す。

変更の追跡

変更の追跡 (CT) が有効になっているデータベースは、Always On 可用性グループに含めることができます。 これ以上の構成は必要ありません。 変更データにアクセスするために CDC テーブル値関数 (TVF) を使用する変更の追跡クライアント アプリケーションには、フェールオーバー後にプライマリ レプリカを検索する機能が必要です。 クライアント アプリケーションが可用性グループ リスナー名を通じて接続する場合、接続要求は常に現在のプライマリ レプリカに適切に送られます。

Note

変更の追跡データは、常にプライマリ レプリカから取得する必要があります。 セカンダリ レプリカから変更データにアクセスしようとすると、次のエラーが発生します。

メッセージ 22117、レベル 16、状態 1、行 1

セカンダリ レプリカのメンバーであるデータベース (セカンダリ データベース) では、変更の追跡はサポートされていません。 プライマリ レプリカで変更の追跡クエリを実行する代わりに、セカンダリ レプリカから AG データベースのデータベース スナップショットを作成し、それを使用して変更データにクエリを実行することもできます。 データベース スナップショットは、SQL Server データベース (ソース データベース) の読み取り専用の静的ビューであるため、データベース スナップショット内の変更の追跡データは、セカンダリ レプリカから AG データベースに対してスナップショットが取得された時点のものになります。

注意

Change Tracking が有効になっているデータベースでフェールオーバーが発生すると、Change Tracking によってデータベースの完全な再起動が必要になるため、新しいプライマリ レプリカでの復旧時間が通常よりも長くなる場合があります。

レプリケーションの使用に関する前提条件、制限、および考慮事項

ここでは、 Always On 可用性グループでレプリケーションを配置する際の前提条件、制限、推奨などの考慮事項について説明します。

前提条件

  • 単一の可用性グループ内でトランザクション レプリケーションとパブリッシング データベースを使用する場合は、パブリッシャーとディストリビューターの両方が少なくとも SQL Server 2012 (11.x) を実行する必要があります。 サブスクライバーは、それより低いレベルの SQL Serverを使用することもできます。

  • 単一の可用性グループ内でマージ レプリケーションとパブリッシング データベースを使用する場合は、次のことが適用されます。

    • プッシュ サブスクリプション: パブリッシャーとディストリビューターの両方が少なくとも SQL Server 2012 (11.x) を実行する必要があります。

    • プル サブスクリプション: パブリッシャー、ディストリビューター、およびサブスクライバー データベースは、少なくとも SQL Server 2012 (11.x) 上にある必要があります。 これは、可用性グループがセカンダリにフェールオーバーする方法を、サブスクライバー上のマージ エージェントが把握しておく必要があることが原因です。

  • パブリッシャーのインスタンスは、Always On 可用性グループに参加するために必要なすべての前提条件を満たす必要があります。 詳細については、「Always On 可用性グループの前提条件、制限事項、および推奨事項 (SQL Server)」を参照してください。

制限

Always On 可用性グループのレプリケーションでサポートされている組み合わせは次のとおりです。

レプリケーション Publisher ディストリビューター1 サブスクライバー (Subscriber)
トランザクション はい

注:双方向の相互トランザクション レプリケーションのサポートは含まれません。		 はい はい
ピア ツー ピア2 はい ○3 はい
[マージ] はい いいえ いいえ
スナップショット はい いいえ はい
トランザクション レプリケーションの更新可能なサブスクリプション いいえ 番号 いいえ

1 データベース ミラーリングでディストリビューター データベースを使用することはできません。

2 SQL Server 2019 CU 13 以降が必要です。

3 SQL Server 2019 CU 17 以降が必要です。

考慮事項

  • データベース ミラーリングでディストリビューション データベースを使用することはできませんが、一定の制限を条件として Always On 可用性グループでは使用できます。ディストリビューション可用性グループの設定に関するページを参照してください。 レプリケーション構成は、ディストリビューターが構成された SQL Server インスタンスと結び付けられます。そのため、ディストリビューション データベースはミラー化またはレプリケートできません。 SQL Server のフェールオーバー クラスターを使用してディストリビューターの高可用性を実現することもできます。 詳細については、「Always On フェールオーバー クラスター インスタンス (SQL Server)」を参照してください。

  • セカンダリ データベースへのサブスクライバーのフェールオーバーはサポートされていますが、マージ レプリケーション サブスクライバーの手動手順となります。 手順は、ミラー化されたサブスクライバー データベースをフェールオーバーするために使用される方法と本質的には同じです。 トランザクション レプリケーション サブスクライバーの場合、 Always On 可用性グループに参加している間、特別な処理は必要ありません。 可用性グループに参加するには、サブスクライバーは SQL Server 2012 (11.x) 以降を実行している必要があります。 詳細については、「 レプリケーション サブスクライバーと AlwaysOn 可用性グループ (SQL Server)」を参照してください。

  • ログイン、ジョブ、リンク サーバーなど、データベースの外部に存在するメタデータやオブジェクトはセカンダリ レプリカに反映されません。 フェールオーバー後に新しいプライマリ データベースでこれらのメタデータやオブジェクトが必要な場合は、手動でコピーする必要があります。 詳しくは、「可用性グループのデータベースのためのログインとジョブの管理 (SQL Server)」をご覧ください。

分散型可用性グループ

可用性グループ内のパブリッシャーまたはディストリビューション データベースは、分散型可用性グループの一部として構成することはできません。 可用性グループ内のパブリッシャー データベースと可用性グループ内のディストリビューション データベースはいずれも、適切に構成および使用するためにはリスナー エンドポイントが必要です。 ただし、分散型可用性グループに対してリスナー エンドポイントを構成することはできません。

Related Tasks

レプリケーション

変更データのキャプチャ

Change tracking

参照

レプリケーション サブスクライバーと AlwaysOn 可用性グループ (SQL Server)
Always On 可用性グループの前提条件、制限事項、推奨事項 (SQL Server)
Always On 可用性グループの概要 (SQL Server)
Always On 可用性グループ: 相互運用性 (SQL Server)
Always On フェールオーバー クラスター インスタンス (SQL Server)
変更データ キャプチャについて (SQL Server)
変更の追跡について (SQL Server)
SQL Server レプリケーション
データ変更の追跡 (SQL Server)
sys.sp_cdc_add_job (Transact-SQL)