次の方法で共有

レプリケーション、変更の追跡、変更データ キャプチャ、および AlwaysOn 可用性グループ (SQL Server)

  • [アーティクル]

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

AlwaysOn 可用性グループでのレプリケーションの概要

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

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

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

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

Note

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

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

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

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

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

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

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

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

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

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

  • トレース フラグ 1448

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

AlwaysOn をサポートするストアド プロシージャ

  • 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

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

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

変更データ キャプチャ

変更データ キャプチャ (CDC) に対して有効になっているデータベースは、Always On 可用性グループを利用して、障害が発生してもデータベースが引き続き使用できることを保証できるだけでなく、データベース テーブルへの変更が引き続き監視され、CDC 変更テーブルに格納されるようにすることができます。 CDC 可用性グループと Always On 可用性グループを構成する順序は重要ではありません。 CDC 対応データベースを Always On 可用性グループに追加でき、AlwaysOn 可用性グループのメンバーであるデータベースを 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 ジョブも無効にする必要があります。 ジョブを無効/有効にするには、sp_update_job (Transact-SQL) の @enabled オプションを使用します。 CDC ジョブの作成の詳細については、「sys.sp_cdc_add_job (Transact-SQL)を参照してください。

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

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

  • 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'SQLNCLI11',   
@datasrc=N'AG_Listener_Name',   
@provstr=N'ApplicationIntent=ReadOnly',   
@catalog=N'MY_DB_NAME';

  • CDC 変更データとドメイン ログインへのクライアント アクセス

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

変更の追跡

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

Note

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

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

セカンダリ レプリカのメンバーであるデータベース (セカンダリ データベース) では、変更の追跡はサポートされていません。 変更の追跡クエリをプライマリ レプリカのデータベースに対して実行します。

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

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

前提条件

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

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

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

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

  • ディストリビューション データベースを可用性グループに配置することはサポートされていません。

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

制限

Always On 可用性グループでサポートされているレプリケーションの組み合わせ:
発行元 ディストリビューター 3 サブスクライバー
トランザクション 可1 いいえ はい2
P2P いいえ いいえ いいえ
[マージ] はい いいえ はい2
スナップショット はい いいえ はい2

1 双方向および逆トランザクション レプリケーションのサポートは含まれません。

2 レプリカ データベースへのフェールオーバーは手動で行います。 自動フェールオーバーは提供されていません。

3 ディストリビューター データベースは、Always On 可用性グループまたはデータベース ミラーリングでの使用はサポートされていません。

考慮事項

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

  • セカンダリ データベースへのサブスクライバーのフェールオーバーはサポートされていますが、かなり複雑な手動での手順になります。 手順は、ミラー化されたサブスクライバー データベースをフェールオーバーするために使用される方法と本質的には同じです。 可用性グループに参加するには、サブスクライバーが SQL Server 2012 以降を実行している必要があります。

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

Related Tasks

レプリケーション

変更データのキャプチャ

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)