Azure SQL Managed Instance でのトランザクション レプリケーション

適用対象: Azure SQL Managed Instance

トランザクション レプリケーションは、Azure SQL Managed Instance または SQL Server インスタンスのテーブルからリモート データベースに配置されているテーブルにデータをレプリケートする、Azure SQL Managed Instance と SQL Server の機能です。 この機能を使用すると、さまざまなデータベース内の複数のテーブルを同期させることができます。

概要

トランザクション レプリケーションを使用して、Azure SQL マネージド インスタンスで行われた変更を以下にプッシュすることができます。

• オンプレミスまたは Azure Virtual Machine 上の SQL Server データベース
• Azure SQL Database 内のデータベース
• Azure SQL Managed Instance 内のインスタンス データベース

Note

Azure SQL Managed Instance のすべての機能を使用するには、最新バージョンの SQL Server Management Studio (SSMS) および SQL Server Data Tools (SSDT) を使用する必要があります。

Components

トランザクション レプリケーションの主要なコンポーネントは、次の図のパブリッシャー、ディストリビューター、サブスクライバーです。

Role	Azure SQL データベース	Azure SQL Managed Instance
発行元	いいえ	はい
ディストリビューター	いいえ	はい
プル サブスクライバー	いいえ	はい
プッシュ サブスクライバー	はい	はい

パブリッシャーにより、ディストリビューターに更新プログラムが送信され、一部のテーブル (アーティクル) に加えられた変更が発行されます。 パブリッシャーには、Azure SQL マネージド インスタンスまたは SQL Server インスタンスを指定できます。

ディストリビューターでは、パブリッシャーからアーティクル内の変更が収集されてサブスクライバーに配布されます。 ディストリビューターには、Azure SQL マネージド インスタンスまたは SQL Server インスタンス (パブリッシャーのバージョン以上の任意のバージョン) のいずれかを指定できます。

サブスクライバーによって、パブリッシャーに対して加えられた変更が受け取られます。 プッシュ サブスクライバーとプル サブスクライバーには、SQL Server インスタンスと Azure SQL マネージド インスタンスの両方を指定できます。ただし、ディストリビューターが Azure SQL マネージド インスタンスであり、サブスクライバーがそうではない場合は、プル サブスクリプションはサポートされません。 Azure SQL Database 内のデータベースは、プッシュ サブスクライバーにしか指定できません。

Azure SQL Managed Instance では、次のバージョンの SQL Server をサブスクライバーに指定できます。

• SQL Server 2016 以降のバージョン
• SQL Server 2014 RTM CU10 (12.0.4427.24) または SP1 CU3 (12.0.2556.4)
• SQL Server 2012 SP2 CU8 (11.0.5634.1) または SP3 (11.0.6020.0) または SP4 (11.0.7001.0)

Note

Azure でのオブジェクトへの発行をサポートしていないその他のバージョンの SQL Server では、データの再発行方法を利用して新しいバージョンの SQL Server にデータを移動することができます。

以前のバージョンを使用してレプリケーションを構成しようとすると、エラーMSSQL_REPL20084 (プロセスはサブスクライバーに接続できませんでした) および MSSQL_REPL40532 (ログインによって要求されたサーバー <名前> を開くことができません) が発生する可能性があります。

レプリケーションの種類

さまざまなレプリケーションの種類があります。

レプリケーション	Azure SQL データベース	Azure SQL Managed Instance
標準トランザクション	はい (サブスクライバーとしてのみ)	はい
スナップショット	はい (サブスクライバーとしてのみ)	はい
マージ レプリケーション	いいえ	いいえ
ピア ツー ピア	いいえ	いいえ
双方向	いいえ	はい
更新可能なサブスクリプション	いいえ	いいえ

サポータビリティ マトリックス

Azure SQL Managed Instance のトランザクション レプリケーションのサポータビリティ マトリックスは、SQL Server のものと同じです。

発行元	ディストリビューター	サブスクライバー
SQL Server 2022	SQL Server 2022	SQL Server 2022 SQL Server 2019 SQL Server 2017
SQL Server 2019	SQL Server 2022 SQL Server 2019	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016
SQL Server 2017	SQL Server 2022 SQL Server 2019 SQL Server 2017	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014
SQL Server 2016	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016	SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012
SQL Server 2014	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014	SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008
SQL Server 2012	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012	SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008
SQL Server 2008 R2 SQL Server 2008	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008	SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008

使用する場合

トランザクション レプリケーションは次のシナリオで役立ちます。

• データベース内の 1 つ以上のテーブルに対して加えられた変更を発行して、変更がサブスクライブされている 1 つ以上の SQL Server インスタンスまたは Azure SQL Database に配布する。
• いくつかの分散データベースは同時状態を保持します。
• 変更を継続的に発行して、データベースを 1 つの SQL Server インスタンスまたは Azure SQL Managed Instance から別のデータベースに移行する。

データ同期とトランザクション レプリケーションの比較

カテゴリ	データ同期	トランザクション レプリケーション
長所	- アクティブ/アクティブのサポート - オンプレミスと Azure SQL Database 間で双方向	- 待ち時間の短縮 - トランザクションの整合性 - 移行後に既存のトポロジの再利用
短所	- トランザクションの整合性なし - パフォーマンスへの影響が大きい	- Azure SQL Database からは発行できない - 高いメンテナンス コスト

一般的な構成

一般に、パブリッシャーとディストリビューターは、クラウドかオンプレミスのいずれかに存在する必要があります。 次の構成がサポートされています。

SQL Managed Instance 上のパブリッシャーとローカルのディストリビューター

パブリッシャーとディストリビューターは、1 つの SQL マネージド インスタンス内に構成され、別の SQL マネージド インスタンス、SQL Database、または SQL Server インスタンスに変更を配布します。

SQL Managed Instance 上のパブリッシャーとリモート ディストリビューター

この構成では、多くのソース SQL マネージド インスタンスにサービスを提供し、Azure SQL Database、Azure SQL Managed Instance または SQL Server 上の 1 つまたは多数のターゲットに変更を配布できる、別の SQL Managed Instance に配置されているディストリビューターに、1 つの SQL マネージド インスタンスにより変更が発行されます。

2 つのマネージド インスタンス上にパブリッシャーとディストリビューターが構成されています。 この構成には、次のようないくつかの制約があります。

• 2 つのマネージド インスタンスが同じ vNet 上にあります。
• 2 つのマネージド インスタンスが同じ場所にあります。

リモートにサブスクライバーが存在するオンプレミスのパブリッシャー/ディストリビューター

この構成では、Azure SQL Database または Azure SQL Managed Instance 内のデータベースがサブスクライバーです。 この構成では、オンプレミスから Azure への移行がサポートされます。 サブスクライバーが Azure SQL Database のデータベースである場合は、それはプッシュ モードにする必要があります。

必要条件

• レプリケーション参加者間の接続には、SQL 認証を使用します。
• レプリケーションで使用する作業ディレクトリに Azure ストレージ アカウント共有を使用します。
• サブネット セキュリティ規則の TCP 送信ポート 445 を Azure ファイル共有へのアクセス用に開きます。
• SQL マネージド インスタンスがパブリッシャーまたはディストリビューターで、サブスクライバーがそうではない場合は、TCP 送信ポート 1433 を開きます。 また、ポート 1433 宛先サービス タグの allow_linkedserver_outbound の SQL マネージド インスタンス NSG 送信セキュリティ規則を virtualnetwork から internet に変更することが必要になる場合もあります。
• パブリッシャーとディストリビューターを両方ともクラウド、または両方ともオンプレミスに配置します。
• レプリケーション参加者の仮想ネットワークが異なる場合は、仮想ネットワーク間で VPN ピアリングを構成します。

Note

ディストリビューターが Azure SQL Managed Instance データベースでサブスクライバーがオンプレミスであるときに送信ネットワーク セキュリティ グループ (NSG) ポート 445 がブロックされている場合、Azure Storage ファイルに接続するときに、エラー 53 が発生する可能性があります。 vNet NSG を更新して、この問題を解決します。

セキュリティ

replAgentUser にログインします。

トランザクション レプリケーションの目的上、SQL Managed Instance には名前 replAgentUser が付いた事前作成済みログインがあります。 このログインは、sysadmin サーバー ロールのメンバーであり、トランザクション レプリケーションのセットアップに参加している SQL Managed Instance に接続する必要があるレプリケーション エージェントによって使用されます。

トランザクション レプリケーションを使用しない場合は、ログイン replAgentUser を無効にすることができます。 トランザクション レプリケーションの使用を開始する場合は、後で再度有効にすることができます。

制限事項

トランザクション レプリケーションには、Azure SQL Managed Instance に特有の制限がいくつかあります。 このセクションでこれらの制限の詳細を確認してください。

スナップショット ファイルが Azure Storage アカウントから削除されない

Azure SQL Managed Instance では、トランザクション レプリケーションに使用されるスナップショット ファイルに対して、ユーザーが構成した Azure Storage アカウントを使用します。 オンプレミス環境の SQL Server とは異なり、Azure SQL Managed Instance によって Azure Storage アカウントからスナップショット ファイルが削除されません。 ファイルが不要になったら、ユーザーがファイルを削除する必要があります。 これは、Azure portal の Azure Storage インターフェイスである Microsoft Azure Storage Explorer か、コマンド ライン クライアント (Azure PowerShell または CLI) または Azure Storage Management REST API を使用して行うことができます。

ファイルを削除する方法と、空のフォルダーを削除する方法の例を次に示します。

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

継続的に実行されているディストリビューション エージェントの数

継続的に実行するように構成されたディストリビューション エージェントの数は、Azure SQL Managed Instance では 30 に制限されています。 より多くのディストリビューション エージェントを使用するには、オンデマンドまたは定義されたスケジュールで実行する必要があります。 スケジュールは毎日かつ 10 秒 (またはそれ以上) ごとの頻度で定義できるため、連続とはいかないまでも、待機時間がわずか数秒のディストリビューターを引き続き使用できます。 多数のディストリビューターが必要な場合は、継続的な構成ではなく、スケジュールされた構成を使用することをお勧めします。

フェールオーバーグループを使う

フェールオーバー グループ内のインスタンスでのトランザクション レプリケーションの使用はサポートされています。 ただし、SQL マネージド インスタンスをフェールオーバー グループに追加する前にレプリケーションが構成されている場合、フェールオーバー グループの作成を開始するとレプリケーションが一時停止し、レプリケーション モニターに Replicated transactions are waiting for the next log backup or for mirroring partner to catch up の状態が表示されます。 レプリケーションは、フェールオーバー グループが正常に作成されると、再開されます。

パブリッシャーまたはディストリビューター SQL マネージド インスタンスがフェールオーバー グループに存在する場合、フェールオーバーが発生した後に、SQL マネージド インスタンス管理者が、古いプライマリ上のすべてのパブリケーションをクリーンアップして、新しいプライマリ上でそれらを再構成する必要があります。 このシナリオでは、次のアクティビティが必要です。

1. データベース上で実行されているレプリケーション ジョブがある場合は、すべて停止します。

2. パブリッシャーからサブスクリプションのメタデータを削除するには、パブリッシャー データベース上で次のスクリプトを実行します。 <name of publication> と <name of subscriber> の各値を置き換えます。

   EXEC sp_dropsubscription @publication = '<name of publication>',
       @article = 'all',
       @subscriber = '<name of subscriber>'
   

3. サブスクライバーからサブスクリプションのメタデータを削除します。 サブスクライバー SQL マネージド インスタンス上のサブスクリプション データベースで、次のスクリプトを実行します。 <full DNS of publisher> の値を置き換えます。 example.ac2d23028af5.database.windows.net の例を次に示します。

   EXEC sp_subscription_cleanup
      @publisher = N'<full DNS of publisher>',
      @publisher_db = N'<publisher database>',
      @publication = N'<name of publication>';
   

4. パブリッシャーからすべてのレプリケーション オブジェクトを強制的に削除するには、発行されたデータベースで次のスクリプトを実行します。

   EXEC sp_removedbreplication;
   

5. 元のプライマリ SQL マネージド インスタンスから以前のディストリビューターを強制的に削除します (ディストリビューターが以前は存在していた以前のプライマリにフェールバックする場合)。 以前のディストリビューター SQL マネージド インスタンスの master データベース上で次のスクリプトを実行します。

   EXEC sp_dropdistributor 1, 1;
   

サブスクライバー SQL マネージド インスタンスがフェールオーバー グループにある場合、パブリケーションがそのサブスクライバー SQL マネージド インスタンスのフェールオーバー グループのリスナー エンドポイントに接続するように構成されている必要があります。 フェールオーバーが発生した場合、SQL マネージド インスタンス管理者による以降のアクションは、発生したフェールオーバーの種類によって異なります。

• データ損失のないフェールオーバーの場合、フェールオーバー後もレプリケーションは機能し続けます。
• データ損失を伴うフェールオーバーの場合、レプリケーションも機能します。 これにより、失われた変更が再度レプリケートされます。
• データ損失を伴うフェールオーバーであるが、データ損失がディストリビューション データベースの保持期間外である場合は、SQL マネージド インスタンス管理者がサブスクリプション データベースを再初期化する必要があります。

一般的な問題のトラブルシューティング

トランザクション ログとトランザクション レプリケーション

通常の状況では、データベース内のデータの変更を記録するためにトランスケーション ログが使用されます。 変更はトランザクション ログに記録され、ログ ストレージの使用量が増加します。 トランザクション ログの安全な切り捨てを可能にする自動プロセスもあり、このプロセスにより、ログに使用される記憶領域が削減されます。 トランザクション レプリケーションの発行が構成されている場合、ログの変更がログ リーダー ジョブによって処理されるまで、トランザクション ログの切り捨ては行われません。 状況によっては、トランザクション ログの処理が効果的にブロックされる状態になるため、トランザクション ログ用に予約されているストレージ全体がいっぱいになることがあります。 トランザクション ログの空き領域がなく、トランザクション ログを拡張するための領域がなくなった場合は、完全なトランザクション ログが作成されます。 この状態では、データベースは書き込みワークロードを処理できなくなり、実質的に読み取り専用データベースになります。

無効なログ リーダー エージェント

トランザクション レプリケーション パブリケーションがデータベース用に構成されていても、ログ リーダー エージェントが実行するように構成されていない場合があります。 その場合、変更はトランザクション ログに蓄積され、処理されません。 これにより、トランザクション ログが継続的に増加し、最終的には完全なトランスケーション ログが作成されます。 ユーザーは、ログ リーダー ジョブが存在し、アクティブであることを確認する必要があります。 代替案としては、トランザクション レプリケーションが不要な場合は、無効にすることもできます。

ログ リーダー エージェントのクエリ タイムアウト

クエリのタイムアウトが繰り返されるため、ログ リーダー ジョブが効果的に進行できない場合があります。 クエリ タイムアウトを修正するには、ログ リーダー エージェント ジョブのクエリ タイムアウト設定を増やします。

ログ リーダー ジョブのクエリ タイムアウトを増やすには、SSMS を使用します。 オブジェクト エクスプローラーの SQL Server エージェントで、変更するジョブを見つけます。 最初にそれを停止し、そのプロパティを開きます。 step 2 を見つけて編集します。 コマンド値に -QueryTimeout <timeout_in_seconds> を追加します。 クエリ タイムアウト値には 21600 以上を試します。 最後に、ジョブをもう一度開始します。

ログ ストレージのサイズが最大制限の 2 TB (テラバイト)に達しました

トランザクション ログのストレージ サイズが最大制限 (2 TB (テラバイト)) に達した場合、ログはそれ以上増加することはできません。 この場合、使用可能な唯一の軽減策は、トランザクション ログを切り捨てることができるように、レプリケートされるすべてのトランザクションを処理済みとしてマークすることです。 これは、実質的にログ内の残りのトランザクションはレプリケートされず、レプリケーションを再初期化する必要があることを意味します。

Note

軽減策を実行した後、レプリケーションを再初期化する必要があります。つまり、データ セット全体を再度レプリケートするということです。 これはデータ操作のサイズであり、レプリケートする必要があるデータの量によっては実行時間が長い場合があります。

軽減策を実行するには、まずディストリビューターでログ リーダー エージェントを停止する必要があります。 次に、トランザクション ログの切り捨てを許可するために、パブリッシャー データベースで sp_repldone フラグを 1 に設定して reset ストアド プロシージャを実行する必要があります。 コマンドは次の EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1 のようになります。 その後、レプリケーションを再初期化する必要があります。

次のステップ

トランザクション レプリケーションの構成の詳細については、次に関するチュートリアルを参照してください。

• SQL Managed Instance パブリッシャーとサブスクライバーの間でのレプリケーションの構成。
• SQL Managed Instance パブリッシャー、SQL Managed Instance ディストリビューター、SQL Server サブスクライバー間でのレプリケーションの構成。
• パブリケーションを作成します。
• プッシュ サブスクリプションの作成: サーバー名をサブスクライバーとして使用し (例: N'azuresqldbdns.database.windows.net)、Azure SQL Database 名のデータベースを宛先データベースとして使用します (例: Adventureworks)。

関連するコンテンツ

• SQL Managed Instance とフェールオーバー グループのレプリケーション
• SQL Database へのレプリケーション
• マネージド インスタンスへのレプリケーション
• パブリケーションを作成する
• プッシュ サブスクリプションを作成する
• レプリケーションの種類
• 監視 (レプリケーション)
• サブスクリプションを初期化する