はじめに
こんにちはDXソリューション統括部の鈴木です。
今回は、Azure SQL Managed Instance(以下SQL MI)を使用したトランザクションレプリケーションにおいて、所謂同期元となるパブリッシャー及びディストリビューターの不可能な構成について、自身の忘備録も兼ねてご説明できればと思います。
また、実際に構成を検討する際にポイントとなりそうな「費用・処理負荷・同期時間」の観点から、それぞれ妥当な構成案をご紹介します。
なお、トランザクションレプリケーションはSQL MIのみを使用するパターンやパブリッシャー/ディストリビューターにオンプレミスを使用するパターン等がありますが、今回はSQL MIのみを使用する場合に限定しています。
本記事の前提知識となる「SQL MI」「トランザクションレプリケーション」等については、以下記事をご参照ください。
パブリッシャーとディストリビューターの不可能な構成
まず、パブリッシャーとディストリビューターの構成における大前提をお伝えします。
それは、「１つのパブリッシャーから見てディストリビューターは１つ」ということです。
１つのパブリッシャーは、たとえパブリケーションが複数あった場合でも、複数のディストリビューターと紐づくことはできません。
そのため１つのパブリッシャーにおいて「パブリケーション①はディストリビューター①に、パブリケーション②はディストリビューター②に紐づけたい」というようなことはできません。
より分かりやすく表現するならば、１つの同期元SQL MIからデータベース毎に使用するディストリビューターを選択することはできない、ということです。１つのパブリッシャーに存在するデータベースは、みな同じディストリビューターを使用するほかに道はないのです。
↑の図はリモートディストリビューターのみを使用する環境となっていますが、↓の図のようにローカルディストリビューターを使用する環境においても、１つのパブリッシャーからローカル&リモートディストリビューターに紐づけることは同様の理由で×となります。
逆に、１つのディストリビューターは複数のパブリッシャーを有効化することができます。つまり、複数のパブリッシャーから紐づけられることは可能です。
これはローカルorリモートディストリビューターを問いません。そのため「パブリッシャー①がディストリビューター①をローカルディストリビューターとして使用するのに加え、パブリッシャー②がリモートディストリビューターとしてディストリビューター①を使用する」のは〇です。
因みに、ディストリビューターからパブリッシャーを有効化するには以下の手順で実行可能です。
・GUI版：ディストリビューターでのリモート パブリッシャーの有効化 (SSMS) – SQL Server | Microsoft Learn
・Transact-SQL版：Azure SQL Managed Instance と SQL Server の間にトランザクション レプリケーションを構成する – Azure SQL Managed Instance | Microsoft Learn
費用と処理負荷と同期時間
ここまでパブリッシャー・ディストリビューターの不可能な構成についてご説明してきましたが、実際にパブリッシャーとディストリビューターの構成を考える際、「費用・処理負荷・同期時間」の三点がポイントになるのではないかと思います。
以降でそれぞれの観点において妥当な構成案をご紹介します。
費用
まず一番費用が抑えられるのは、ローカルディストリビューターを使用する構成、つまり１つのSQL MIをパブリッシャー兼ディストリビューターにする構成です。
リモートディストリビューターを使用する場合のようにパブリッシャー用とディストリビューター用でそれぞれSQL MIを(最低2台)用意する必要が無いため、その分SQL MI自体にかかるコストを削減することができます。
なお、SQL MIの計算シミュレーションはこちらから可能です↓
価格 – Azure SQL Managed Instance 単一インスタンス | Microsoft Azure
処理負荷
次に、処理負荷の観点で一番リソースにとって優しいと言える構成は、リモートディストリビューターを使用する構成です。
既に図の中で登場していますが、ディストリビューターはパブリッシャーと同じサーバーであるかそうでないかでそれぞれ「ローカルディストリビューター」「リモートディストリビューター」と呼ばれています。
パブリッシャーとは別のサーバーとするリモートディストリビューターを選択する主な観点は、「パブリッシャーの処理負荷影響を最小限とするために分離させる」ことにあり、ディストリビューターの役割が大きいトランザクションレプリケーションにおいては、リモートディストリビューターの方が処理負荷の観点では適切と言えます。
そのため、レプリケーションエージェント等の負荷軽減策を考えるのであれば、
①リモートディストリビューターの採用
②１つのパブリッシャーから見て１つのディストリビューターとなるよう、レプリケーションの構成をスケールアウトする
の二点が有効かと思います。
※ディストリビューターのみ増やすことは構成としてできません。
ローカル/リモートディストリビューターについては以下をご参照ください↓
ディストリビューションの構成 – SQL Server | Microsoft Learn
同期時間
最後に同期にかかる時間ですが、これはトランザクションの大きさ等様々な要素に依るところでもあり、「ローカルorリモートディストリビューターの方が良い」と断言することはできません。
しかし、パブリッシャー・ディストリビューター間の同期時間という観点では、パブリッシャー・ディストリビューター間のネットワーク通信が発生しないローカルディストリビューターの方が、同期にかかる時間は短くなる可能性があります。(パブリッシャーの処理の負荷影響がない場合)
また、トランザクションレプリケーション全体で考えた際、パブリッシャー&ディストリビューターとサブスクライバーで異なるVNetに存在する場合は、二つのVNetをどう接続するかというのも同期時間に影響する要素の一つとなります。
おわりに
以上、①パブリッシャーとディストリビューターで可能な構成②三つの観点から見る妥当な構成 の二点をご説明しました。
実際にSQL MIによるトランザクションレプリケーションを構成する際は、「パブリケーションとディストリビューターはN対１」ということを前提に、予算や想定される処理量、目的等を踏まえてご検討いただければと思います。
最後までお読みいただきありがとうございました！
(この記事が参考になった人の数：2)
読み込み中...