サイト間 VPN をまたぐ push と pull のレプリケーションエージェント

エージェントの位置、データの位置ではなく、それが SQL Server サブスクリプションを形づくる判断です。エージェントを実行するマシンが接続を開き、特定のアカウントで動作し、同期が止まったときの責任を負います。サイト間 VPN では、その違いこそが設計であり、細部ではありません。ネットワークを描く前にエージェントの接続を描いてください。

三つの役割、二つではない

Publisher は記事のデータを所有し、Distributor はディストリビューション データベースを所有し、Subscriber は変更を受け取ります。Log Reader Agent はトランザクション レプリケーションのために Distributor で実行されます。Distribution Agent はサブスクリプションの種類によって位置が変わるエージェントであり、だからこそネットワーク設計を左右します。VPN のルールを語る前に、これらの役割を整理してください。

push サブスクリプションは Distribution Agent を Distributor で実行し、pull サブスクリプションはそれを Subscriber で実行します。これは Microsoft のサブスクリプションのドキュメントに書かれているとおりです。ネットワークのやり取りはすべて、それがどのマシンかにかかっています。サブスクリプションごとに四つの事実を書き留めてください。エージェントのホスト、そのプロセスの ID、使用するデータベース ログイン、到達すべきリソースです。図の矢印ではなく、これらの事実が、どちらの方向が機能すべきかを教えてくれます。

push とは、エージェントが Distributor に住むということです

push サブスクリプションでは、Distributor が VPN 越しに Subscriber への接続を開きます。サブスクライバー側のリスナー、ファイアウォール、SQL ログインは、リモート側から届く接続を受け入れる必要があります。Distributor のサービス アカウントには、サブスクライバー データベース上の権限も必要です。サブスクリプションを作成する前に、この受信経路を計画してください。後から気づくことは、たいてい作り直しを意味します。

スナップショットの配信は、定常レプリケーションが決して使わない経路を追加します。スナップショットがファイル共有に置かれている場合、Distribution Agent はその共有から読み取り、サブスクライバーのアカウントは同じ UNC パスに到達しなければなりません。何週間も流れ続ける変更ストリームは、再初期化が機能するかどうかについて何も語りません。だからこそスナップショット共有は最初から計画に入れるべきです。

push を一方向のトラフィックと読まないでください。エージェントには応答、確認応答、そして独自の認証のやり取りが必要です。データが一方向に流れる場合でも、経路は接続レベルで双方向でなければなりません。

pull とは、エージェントが Subscriber に住むということです

pull サブスクリプションは接続を反転させます。Subscriber が Distribution Agent を実行し、Distributor に働きかけます。この配置は、支社からの外向き接続を許可し、内向き接続をブロックする VPN ポリシーに適しています。また、スケジュールの判断を支社サーバーの面倒を見る人の手に委ねます。支社のチームが自らの同期を所有し、自らの失敗に気づくべき場合は、これを選んでください。

サブスクライバーの SQL Server Agent サービス アカウントには、ディストリビューション データベースとスナップショット共有への読み取りアクセスが必要です。そのアカウントはレプリケーション エラーに現れる識別情報であり、ドメイン権限のないローカル サービス アカウントは、ネットワーク障害に見えて実は資格情報の障害である地点で失敗します。トンネルをデバッグする前にアカウントを確認してください。ログインを直すほうが、ネットワークの無実を証明するよりたいてい速いです。

所有権はエージェントに従います。スケジュールと失敗の両方を中央チームが持つべき場合は push を選んでください。どちらを選んでも、次のエンジニアが最初に見る場所を知れるよう、サブスクリプションのそばに書き留めてください。

再パブリッシュが変えるのはファンアウトであり、所有権ではありません

サブスクライバーをさらに別のサブスクライバーへ再パブリッシュするよう構成でき、これにより一つの支社データベースが、それぞれが WAN 越しに引っ張ることなく複数のローカル コンシューマーにサービスを提供できます。中間のデータベースは今やパブリケーションと独自のエージェントを持ちます。以前にはなかった権限、監視、復旧計画も継承します。その追加の役割が、繰り返される WAN 配信を取り除く代価です。

文書化された順序が重要です。下流のパブリケーションを作成する前に、受信サブスクリプションを初期化してください。これを飛ばしてよい事務作業ではなく、検証を伴うライフサイクルの手順として扱ってください。逆にすると、構成済みに見えて何も配信しない連鎖が生まれます。

書き込みモデルを明示してください。読み取り専用のデータセットをローカル コンシューマーにレプリケートすることは、複数サイトで書き込みを受け入れることとは別の設計であり、矢印の連鎖が競合解決を生むわけではありません。支社が書き込む必要があるなら、それは独自のトポロジーを持つ別の判断です。依存関係も見えるようにしてください。再パブリッシャーが止まると、その下のすべてのコンシューマーが古くなります。

配置を端から端まで証明してください

記憶を信じるのではなく、ディストリビューション データベースからサブスクリプションの種類を読み取り、変更が実際に届くことを確認してください：

USE distribution;
SELECT publication, subscriber_db, subscription_type
FROM dbo.MSsubscriptions;
EXEC sp_replmonitorsubscriptionpendingcmds
  @publisher = 'PUB1', @publisher_db = 'Sales',
  @publication = 'SalesPub', @subscriber = 'BR1',
  @subscriber_db = 'Sales';

subscription_type が 0 なら push、1 なら pull で、その場では変更できないため、不一致はサブスクリプションを編集するのではなく作り直すことを意味します。保留コマンドの呼び出しは、選んだエージェントが仕事を動かしているのか、単に動いているだけなのかを教えてくれます。保留コマンドがゼロだと報告するのにサブスクライバー テーブルが空のままのサブスクリプションは、滞留が増えていると報告するものとは別の障害であり、両者は別の所有者に導きます。

実際の変更で締めくくります。Publisher で一行を挿入または更新し、エージェントの報告を待って、その行を Subscriber で読み取ります。 短い VPN 中断をまたいでもう一度行い、エージェントがどう回復するかを見ます。そのテストを生き延びたサブスクリプションには、文書化して擁護できる配置があります。