SQL MIのトランザクションレプリケーションにおける同期元の構成について

はじめに

こんにちはDXソリューション統括部の鈴木です。 

 

今回は、Azure SQL Managed Instance(以下SQL MI)を使用したトランザクションレプリケーションにおいて、所謂同期元となるパブリッシャー及びディストリビューターの不可能な構成について、自身の忘備録も兼ねてご説明できればと思います。 

また、実際に構成を検討する際にポイントとなりそうな「費用・処理負荷・同期時間」の観点から、それぞれ妥当な構成案をご紹介します。

 

なお、トランザクションレプリケーションはSQL MIのみを使用するパターンやパブリッシャー/ディストリビューターにオンプレミスを使用するパターン等がありますが、今回はSQL MIのみを使用する場合に限定しています。 

 

本記事の前提知識となる「SQL MI」「トランザクションレプリケーション」等については、以下記事をご参照ください。

Azure SQL Managed Instanceとは

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

パブリッシャー、ディストリビューターとは

 

パブリッシャーとディストリビューターの不可能な構成

まず、パブリッシャーとディストリビューターの構成における大前提をお伝えします。

それは、「1つのパブリッシャーから見てディストリビューターは1つ」ということです。

1つのパブリッシャーは、たとえパブリケーションが複数あった場合でも、複数のディストリビューターと紐づくことはできません。

 

そのため1つのパブリッシャーにおいて「パブリケーション①はディストリビューター①に、パブリケーション②はディストリビューター②に紐づけたい」というようなことはできません。

より分かりやすく表現するならば、1つの同期元SQL MIからデータベース毎に使用するディストリビューターを選択することはできない、ということです。1つのパブリッシャーに存在するデータベースは、みな同じディストリビューターを使用するほかに道はないのです。

↑の図はリモートディストリビューターのみを使用する環境となっていますが、↓の図のようにローカルディストリビューターを使用する環境においても、1つのパブリッシャーからローカル&リモートディストリビューターに紐づけることは同様の理由で×となります。

 

逆に、1つのディストリビューターは複数のパブリッシャーを有効化することができます。つまり、複数のパブリッシャーから紐づけられることは可能です。

これはローカルorリモートディストリビューターを問いません。そのため「パブリッシャー①がディストリビューター①をローカルディストリビューターとして使用するのに加え、パブリッシャー②がリモートディストリビューターとしてディストリビューター①を使用する」のは〇です。

 

因みに、ディストリビューターからパブリッシャーを有効化するには以下の手順で実行可能です。

・GUI版:ディストリビューターでのリモート パブリッシャーの有効化 (SSMS) – SQL Server | Microsoft Learn

・Transact-SQL版:Azure SQL Managed Instance と SQL Server の間にトランザクション レプリケーションを構成する – Azure SQL Managed Instance | Microsoft Learn

 

費用と処理負荷と同期時間

ここまでパブリッシャー・ディストリビューターの不可能な構成についてご説明してきましたが、実際にパブリッシャーとディストリビューターの構成を考える際、「費用・処理負荷・同期時間」の三点がポイントになるのではないかと思います。

以降でそれぞれの観点において妥当な構成案をご紹介します。

 

費用

まず一番費用が抑えられるのは、ローカルディストリビューターを使用する構成、つまり1つのSQL MIをパブリッシャー兼ディストリビューターにする構成です。

リモートディストリビューターを使用する場合のようにパブリッシャー用とディストリビューター用でそれぞれSQL MIを(最低2台)用意する必要が無いため、その分SQL MI自体にかかるコストを削減することができます。

 

なお、SQL MIの計算シミュレーションはこちらから可能です↓

価格 – Azure SQL Managed Instance 単一インスタンス | Microsoft Azure

 

処理負荷

次に、処理負荷の観点で一番リソースにとって優しいと言える構成は、リモートディストリビューターを使用する構成です。

 

既に図の中で登場していますが、ディストリビューターはパブリッシャーと同じサーバーであるかそうでないかでそれぞれ「ローカルディストリビューター」「リモートディストリビューター」と呼ばれています。

パブリッシャーとは別のサーバーとするリモートディストリビューターを選択する主な観点は、「パブリッシャーの処理負荷影響を最小限とするために分離させる」ことにあり、ディストリビューターの役割が大きいトランザクションレプリケーションにおいては、リモートディストリビューターの方が処理負荷の観点では適切と言えます。

 

そのため、レプリケーションエージェント等の負荷軽減策を考えるのであれば、

①リモートディストリビューターの採用

②1つのパブリッシャーから見て1つのディストリビューターとなるよう、レプリケーションの構成をスケールアウトする

の二点が有効かと思います。

※ディストリビューターのみ増やすことは構成としてできません。

 

ローカル/リモートディストリビューターについては以下をご参照ください↓

ディストリビューションの構成 – SQL Server | Microsoft Learn

 

同期時間

最後に同期にかかる時間ですが、これはトランザクションの大きさ等様々な要素に依るところでもあり、「ローカルorリモートディストリビューターの方が良い」と断言することはできません。

 

しかし、パブリッシャー・ディストリビューター間の同期時間という観点では、パブリッシャー・ディストリビューター間のネットワーク通信が発生しないローカルディストリビューターの方が、同期にかかる時間は短くなる可能性があります。(パブリッシャーの処理の負荷影響がない場合)

また、トランザクションレプリケーション全体で考えた際、パブリッシャー&ディストリビューターとサブスクライバーで異なるVNetに存在する場合は、二つのVNetをどう接続するかというのも同期時間に影響する要素の一つとなります。

 

おわりに

以上、①パブリッシャーとディストリビューターで可能な構成②三つの観点から見る妥当な構成 の二点をご説明しました。

実際にSQL MIによるトランザクションレプリケーションを構成する際は、「パブリケーションとディストリビューターはN対1」ということを前提に、予算や想定される処理量、目的等を踏まえてご検討いただければと思います。

最後までお読みいただきありがとうございました!

いいね (←参考になった場合はハートマークを押して評価お願いします)
読み込み中...

注意事項・免責事項

※技術情報につきましては投稿日時点の情報となります。投稿日以降に仕様等が変更されていることがありますのでご了承ください。

※公式な技術情報の紹介の他、当社による検証結果および経験に基づく独自の見解が含まれている場合がございます。

※これらの技術情報によって被ったいかなる損害についても、当社は一切責任を負わないものといたします。十分な確認・検証の上、ご活用お願いたします。

※当サイトはマイクロソフト社によるサポートページではございません。パーソルプロセス&テクノロジー株式会社が運営しているサイトのため、マイクロソフト社によるサポートを希望される方は適切な問い合わせ先にご確認ください。
 【重要】マイクロソフト社のサポートをお求めの方は、問い合わせ窓口をご確認ください