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

[アーティクル]
02/18/2014

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

このトピックの内容

AlwaysOn 可用性グループでのレプリケーションの概要
- パブリッシャーリダイレクト
- AlwaysOn 可用性グループをサポートするためのレプリケーションエージェントへの変更
- AlwaysOn をサポートするストアドプロシージャ
- 変更データキャプチャ
- 変更の追跡
AlwaysOn 可用性グループでレプリケーションを使用する際の前提条件、制限事項、および考慮事項
関連タスク

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

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

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

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

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

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

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

(一番上へ)

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

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

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

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

(一番上へ)

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

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

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

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

パブリッシャーに AlwaysOn 可用性レプリカが 2 つ (プライマリが 1 つとセカンダリが 1 つ) しかない場合にフェールオーバーが発生すると、すべてのセカンダリデータベースがオンラインに戻るか、エラーが発生したセカンダリレプリカが可用性グループから削除されるまでログリーダーが前へ進まないため、元のプライマリレプリカはダウンしたままになります。 AlwaysOn がセカンダリデータベースに変更を書き込むことができないので、セカンダリデータベースに対して実行されているログリーダーは前へ進みません。災害復旧機能を維持しながら、ログリーダーが前へ進めるようにするには、ALTER AVAILABITY 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 変更テーブルに格納されることを保証するために、変更データキャプチャ (CDC) が有効になっているデータベースで AlwaysOn 可用性グループを利用できます。 CDC と AlwaysOn 可用性グループの構成順序は重要ではありません。 CDC 対応データベースは AlwaysOn 可用性グループに追加でき、AlwaysOn 可用性グループのメンバーであるデータベースでは CDC を有効にできます。ただし、どちらの場合も、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 ジョブも無効にする必要があります。ジョブを無効または有効にするには、sp_update_job (Transact-SQL) の @enabled オプションを使用します。 CDC ジョブの作成の詳細については、「sys.sp_cdc_add_job (Transact-SQL)」を参照してください。

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

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

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

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

接続要求が常に現在のプライマリレプリカに送られることを保証する。
接続要求が読み取り専用セカンダリレプリカに送られることを保証する。

読み取り専用セカンダリレプリカの検索にルーティングリストを使用する場合は、可用性グループの読み取り専用ルーティングリストも定義する必要があります。読み取り可能セカンダリへのルーティングアクセスの詳細については、「可用性グループリスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)」を参照してください .

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

次のクエリを使用して、可用性グループリスナー名が 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 認証ログインは、セカンダリデータベースのデータにアクセスすることも、データベースユーザーが定義された元のデータベース以外の新しいプライマリデータベースのデータにアクセスすることもできません。

(一番上へ)

変更の追跡

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

注
変更の追跡データは、常にプライマリレプリカから取得する必要があります。セカンダリレプリカから変更データにアクセスしようとすると、次のエラーが発生します。メッセージ 22117、レベル 16、状態 1、行 1 セカンダリレプリカのメンバーであるデータベース (セカンダリデータベース) では、変更の追跡はサポートされていません。変更の追跡クエリをプライマリレプリカのデータベースに対して実行します。

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

メッセージ 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 可用性グループでのレプリケーションの概要

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

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

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

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

変更データキャプチャ

変更の追跡

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

前提条件

制限事項

考慮事項

関連タスク

関連項目

参照

概念

その他のリソース

次の方法で共有

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

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

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

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

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

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

変更データ キャプチャ

変更の追跡

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

前提条件

制限事項

考慮事項

関連タスク

関連項目

参照

概念

その他のリソース

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

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

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

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

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

変更データキャプチャ