SQL Server レプリケーション：DBAのための完全ガイド [2026]

SQL Server レプリケーションとは、データとデータベースオブジェクトをあるデータベースから別のデータベースにコピー・配布し、データベース間で同期することで一貫性を維持するための一連の技術です。この機能により、異なるサーバーや場所にデータの複数のコピーを作成・維持することができ、データの可用性と信頼性を確保できます。

1.2 レプリケーションの目的と利点

SQL Server レプリケーションは複数の重要なビジネスニーズに対応し、データベース管理とデータ配布に大きな利点をもたらします。

複数の場所にわたるデータ分散: レプリケーションにより、地域オフィスやグローバル拠点間でデータを共有し、必要なデータへのローカルアクセスを確保することで運用効率を向上させることができます。これにより、ネットワークレイテンシが短縮され、地理的に分散したユーザーのパフォーマンスが向上します。
高可用性および災害復旧: レプリケーションは、重要なデータのレプリカを複数のサーバーに保持することで冗長性を確保し、ハードウェア障害や災害から保護します。プライマリサーバーに障害が発生した場合、レプリケーションされたコピーはフォールバックソースとして機能し、ダウンタイムとデータ損失を最小限に抑えます。
負荷分散とスケーラビリティ: レプリケーションは読み取り操作を複数のサーバーに分散し、単一のサーバーがボトルネックになることを防ぎます。このアプローチによりシステムパフォーマンスが向上し、データとユーザーの需要の増加に合わせてインフラストラクチャを水平方向に拡張できるようになります。
リアルタイムのレポート作成と分析: レポート作成と分析クエリを複製サーバーにオフロードすることで、本番データベースの負荷を軽減できます。ユーザーは、運用システムに影響を与えることなく、ほぼリアルタイムのデータに対して複雑な分析クエリを実行できるため、パフォーマンスとデータの鮮度の両方を確保できます。
データの統合と統合: レプリケーションは、様々なソースからのデータを単一の統合ビューに統合することを容易にします。これは、複数の支社を持ち、本社でデータを集約する必要がある組織や、分散した運用システムから集中型のデータウェアハウスを構築する組織にとって特に役立ちます。

2. SQL Server レプリケーションアーキテクチャとコンポーネント

SQL Server レプリケーションアーキテクチャは、データベースインフラストラクチャ全体にデータを分散および同期するために連携して動作する複数の相互接続されたコンポーネントで構成されています。このセクションでは、パブリッシャー、ディストリビューター、サブスクライバー、パブリケーション、アーティクル、サブスクリプション、そしてそれらの間のデータフローを調整するエージェントといったコアコンポーネントについて説明します。

出版社： 出版社とは SQL Server hの例ost複製対象のデータを含む1つ以上のデータベース。レプリケーショントポロジにおける権限のあるソースとして機能します。
配信者： ディストリビューターとは SQL Server パブリッシャーとサブスクライバー間のデータフローを管理するインスタンス。ディストリビューターインスタンスはostレプリケーションメタデータとトランザクションを格納するディストリビューションデータベースです。
加入者： 加入者とは SQL Server パブリッシャーから複製されたデータを受信して保存するインスタンス。単一のサブスクライバーインスタンスはost 複数の加入者データベースがあり、それぞれが異なる出版物からデータを受信します。
出版物： パブリケーションは、複製されるデータの種類と、それを購読者にどのように配布するかを定義します。関連する記事をグループ化し、含まれるすべてのオブジェクトに適用されるレプリケーション手法を確立します。
記事： アーティクルはレプリケーションの基本的な構成要素であり、サブスクライバーに配布される個々のデータベースオブジェクトを表します。
サブスクリプション： サブスクリプションは、パブリケーションとサブスクライバー間の関係を確立し、データが宛先データベースに配信される方法とタイミングを定義します。
エージェント： エージェントは、レプリケーションコンポーネント間でデータを移動および同期する実際の作業を実行する特殊なプロセスです。

3.種類 SQL Server Replication

SQL Server 複数のレプリケーションタイプが用意されており、それぞれ特定のデータ分散シナリオとビジネス要件に合わせて設計されています。それぞれのタイプの特徴、利点、制限を理解することは、環境に適したアプローチを選択する上で不可欠です。

3.1 スナップショットレプリケーション

スナップショットレプリケーションは、特定の時点でパブリッシュするデータのスナップショットを取得し、その完全なコピーをサブスクライバーに配信します。次のスナップショットが生成されるまで、それ以降の変更は監視されません。スナップショットレプリケーションは最もシンプルなレプリケーション形式であり、データの変更頻度が低い場合や、多少古いデータでも許容できるシナリオに適しています。

一般的なユースケースとしては、定期的に更新される価格表や為替レートなどの参照データの配布、データウェアハウスの初期データセットの提供、個々の変更を追跡するよりも完全なデータ更新が望ましいシナリオなどが挙げられます。例えば、企業はスナップショットレプリケーションを使用して、更新された製品カタログを1日1回支社に配布することができます。

スナップショットレプリケーションの主な利点は、そのシンプルさ、メンテナンスの手間の少なさ、そして主キーなしでデータを複製できることです。しかし、テーブルロックによるスナップショット生成時の影響が大きいこと、更新間のレイテンシが高いこと、大規模なデータセットや頻繁に変更されるデータには非効率であることなど、大きな欠点もあります。サブスクライバー側で行われた変更はすべて、ost 次のスナップショットが適用されるとき。

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

トランザクションレプリケーションは、個々のトランザクションを発生時に複製することで、パブリッシャーからサブスクライバーへほぼリアルタイムで変更を配信します。これは、ベースラインを確立するための初期スナップショットから開始され、その後、トランザクションログを継続的に監視してパブリッシュされた記事の変更を検出し、サブスクライバーに段階的に配信します。

トランザクションレプリケーションは、高スループットと低レイテンシが求められるサーバー間シナリオに最適です。一般的なユースケースとしては、読み取り操作をサブスクライバーサーバーにオフロードすることでスケーラビリティと可用性を向上させること、ほぼリアルタイムのデータによるデータウェアハウスとレポート作成をサポートすること、複数のサイトから中央の場所にデータを統合すること、バッチ処理を専用サーバーにオフロードすることなどが挙げられます。例えば、eコマースプラットフォームでは、トランザクションレプリケーションを使用して、地域データベース間で同期された在庫データを維持することができます。

トランザクションレプリケーションの利点には、低レイテンシのデータ配信、大規模トランザクションに対する高いスループット、サブスクライバー側でのレプリケートされていない変更の実行などが含まれます。欠点としては、スナップショットレプリケーションに比べて複雑であること、レプリケートされたテーブルに主キーが必要であること、サブスクライバー側で主キー違反などの競合が発生した場合にレプリケーションが中断される可能性があることなどが挙げられます。

3.3 マージレプリケーション

マージレプリケーションは、サブスクライバーがオフラインまたは断続的な接続で作業し、接続が回復した時点で変更を同期する必要がある環境向けに特別に設計されています。このレプリケーションタイプでは、パブリッシャーとサブスクライバーの両方でデータを個別に変更でき、トリガーとメタデータテーブルを使用して変更を追跡し、同期中に変更を自動的にマージできます。

マージレプリケーションは、自律的な変更が発生するモバイルアプリケーションや分散サーバー環境向けに設計されています。ユースケースとしては、モバイルユーザーがオフラインで作業し、後で同期する営業支援システム（SFA）、独立して動作し、定期的にデータを統合するPOSシステム、複数の拠点で共有データを更新する必要がある分散アプリケーションなどが挙げられます。例えば、小売チェーンでは、マージレプリケーションを使用することで、各店舗がローカル在庫を管理しながら中央倉庫システムと同期できるようになります。

マージレプリケーションの利点には、変更を実行できる自律的なサブスクライバーのサポート、断続的なネットワーク接続への耐性、柔軟な競合解決などがあります。欠点としては、セットアップとメンテナンスの複雑さ、メタデータとトリガーの追跡によるパフォーマンスのオーバーヘッド、テーブルへの uniqueidentifier 列の追加、管理と解決を必要とする競合の発生の可能性などが挙げられます。

3.4 ピアツーピアレプリケーション

ピアツーピア・レプリケーションはトランザクション・レプリケーションを基盤としており、複数のサーバーインスタンス（3ノード以上）が対等なピアとして動作することを可能にします。各ノードは同時にパブリッシャーとサブスクライバーの両方として機能します。このトポロジでは、すべてのノードが同一のデータコピーを保持し、読み取りと書き込みの両方の操作を処理できるため、真に分散されたマルチマスター環境が実現します。

ピアツーピアレプリケーションは、読み取り操作のスケールアウトと高可用性を必要とするアプリケーションに適しています。ユースケースとしては、データの一貫性を維持しながらカタログクエリを複数のノードに分散するWebアプリケーション、ノードを個別にオフラインにすることでダウンタイムなしでメンテナンスやアップグレードを行うシナリオ、複数の地域にデータセンターを持つグローバルアプリケーションなどが挙げられます。例えば、世界規模のソフトウェアサポート組織では、異なるタイムゾーンにあるオフィス間でピアツーピアレプリケーションを使用することで、各拠点から最新のデータにローカルアクセスできるようになります。

ピアツーピアレプリケーションの利点には、スケールアウトによる読み取りパフォーマンスの向上、複数のアクティブノードによる高可用性、ほぼリアルタイムのデータ一貫性などが挙げられます。欠点としては、Enterprise Editionが必要となること、複数ノードのトポロジ管理が複雑であること、すべてのノードで同一のスキーマとデータが必要であること、書き込み操作が適切に分割されていない場合に競合が発生する可能性があることなどが挙げられます。

3.5 双方向レプリケーション

双方向レプリケーションは、2サーバー環境向けに特別に設計されたトランザクションレプリケーショントポロジであり、両サーバー間で変更内容の交換が必要になります。各サーバーはデータをパブリッシュし、他方のサーバーから同じデータをサブスクライブすることで、シンプルな双方向同期フローを構築します。ピアツーピアレプリケーションも2ノードをサポートできますが、この特定のシナリオでは双方向レプリケーションの方がパフォーマンスが向上します。

双方向レプリケーションは、高可用性を実現するアクティブ/アクティブ構成や、各サイトにローカル書き込みアクセスが必要な地理的に分散したアプリケーションなど、同期されたデータを持つ2台のアクティブサーバーを必要とするシナリオに適しています。このトポロジでは、データ更新を分割し、競合を防ぐための慎重なアプリケーション設計が必要です。

メリットとしては、2台のサーバー構成に最適なパフォーマンス、ピアツーピアレプリケーションに比べて構成がシンプル、ほぼリアルタイムの同期、マージレプリケーションよりもオーバーヘッドが低いことなどが挙げられます。デメリットとしては、サーバーが2台までしか接続できないこと、競合解決機能が組み込まれていないため慎重なアプリケーション設計が必要、競合を防ぐための適切なパーティション分割戦略が必要となることなどが挙げられます。

3.6 更新可能なサブスクリプション

更新可能なサブスクリプションは、トランザクションレプリケーションを拡張したもので、サブスクライバーがレプリケートされたデータに随時変更を加え、その変更がパブリッシャーや他のサブスクライバーに反映されるようにします。頻繁な双方向更新を目的としたマージレプリケーションやピアツーピアトポロジとは異なり、更新可能なサブスクリプションは、主要なデータフローが一方向（パブリッシャーからサブスクライバー）であるものの、サブスクライバーが時折修正や更新を行う必要があるシナリオを想定しています。

更新可能なサブスクリプションは、次のようなシナリオに適しています。ost 更新はパブリッシャー側で行われますが、サブスクライバー側でも時折更新が必要になります。例えば、主にデータの読み取りを行うものの、ローカルでの修正や更新も必要となる現場オフィスなどです。競合を最小限に抑え、データの一貫性を確保するには、トポロジを慎重に計画する必要があります。

主な利点は、トランザクション・レプリケーションのパフォーマンス特性を維持しながら、サブスクライバー側で制限された書き込み操作を実行できることです。欠点としては、複雑さが増すこと、解決が必要となる競合が発生する可能性があること、即時更新モードにおける2フェーズ・コミット・プロトコルによるパフォーマンス・オーバーヘッド、そしてレプリケートされるすべてのテーブルに主キーが必要であることなどが挙げられます。

3.7 異なるタイプのレプリケーションの比較

レプリケーションタイプ	更新時間	出版社数	リーダーシップ	シナリオを使用する
Snapshot	時点	1	一方向（発行者→購読者）	頻繁に変更されない参照データ（価格表、為替レート）
取引データ	ほぼリアルタイム	1	一方向（発行者→購読者）	高スループットのシナリオ（電子商取引の在庫、データウェアハウス、レポート）
マージ	定期的（接続時）	1	双方向（パブリッシャー↔サブスクライバー）	モバイルアプリケーション、オフラインワーカー (営業支援、フィールドサービス)
ピアツーピア	ほぼリアルタイム	複数（3つ以上）	双方向（すべてのノード）	グローバルなマルチデータセンター展開（ローカルの読み取り/書き込みアクセスを持つ世界中のオフィス）
双方向の	ほぼリアルタイム	2	双方向（両方のサーバー）	2つのデータセンターのアクティブ/アクティブ構成（デュアルサイトの高可用性）
更新可能なサブスクリプション	ほぼリアルタイム	1	主に一方向（時々逆方向の更新）	主に読み取り、時々更新する支社（ローカル訂正）

4.セットアップ SQL Server Replication

4.1 前提条件と要件

4.1.1 ソフトウェア要件

SQL Server レプリケーションには互換性が必要 SQL Server トポロジー内のすべての参加者間でバージョンを同期します。ディストリビュータのバージョンはパブリッシャーのバージョンと同等かそれ以上である必要があり、サブスクライバのバージョンはパブリッシャーのバージョンの2つ以内であれば問題ありません。例えば、 SQL Server 2016年の出版社は複製できる SQL Server 2012 年、2014 年、2016 年、2017 年、または 2019 年の購読者。

4.1.2 権限要件

レプリケーションの設定には、各レベルで特定の権限が必要です。sysadmin固定サーバーロールのメンバーは、すべてのレプリケーション設定タスクを実行できます。より詳細な権限を設定するには、パブリッシャーデータベースとサブスクライバーデータベースのdb_ownerデータベースロールのメンバーである必要があります。

4.2 ステップ1: 配布を構成する

配信の設定はセットアップの最初のステップです SQL Server レプリケーション。

配布を設定するには SQL Server Management Studio：

接続する SQL Server のインスタンス SQL Server ManagementStudio。
オブジェクトエクスプローラーで、 Replication フォルダを選択 配布の設定.
配布構成ウィザードで、次へウェルカムページ。
ソフトウェア設定ページで、下図のように ディストリビューター ページで、トポロジ要件に基づいて次のいずれかのオプションを選択します。
- 現地代理店: 「ServerName は独自のディストリビューターとして機能します」を選択します。 SQL Server パブリッシャーとディストリビューターを同じインスタンス（現在のインスタンス）で実行する場合は、「ディストリビューションデータベースとログを作成します」を選択します。この構成はセットアップが簡単で、小規模な環境や、パブリッシャーとディストリビューター間のネットワーク遅延が問題となる場合に適しています。
- リモートディストリビューター: 「次のサーバーをディストリビューターとして使用する」を選択し、クリックします。追加ディストリビューション処理を別のインスタンスにオフロードする場合は、リモートディストリビュータサーバを指定します。この構成では、レプリケーションボリュームが大きい場合、ワークロードを複数のサーバーに分散することでパフォーマンスが向上します。リモートディストリビュータ名と、パブリッシャーがディストリビュータに接続する際に使用するパスワードを指定する必要があります。
詳しくはこちら次へスナップショットフォルダの場所を指定します。ネットワーク経由でのアクセスを確保するため、ローカルパスではなくUNCパス（\\servername\share\folderなど）を使用してください。
ソフトウェア設定ページで、下図のように 配布データベース ページで、デフォルトのディストリビューションデータベース名 (通常は「distribution」) を受け入れるか、カスタム名を指定して、データファイルとログファイルの場所を構成します。
ソフトウェア設定ページで、下図のように メディア ページで、現在のサーバーがパブリッシャーとして有効になっていることを確認してください。現在のサーバーをディストリビューターとして設定する場合は、このディストリビューターを使用するパブリッシャーを追加できます。
ウィザードのアクションを確認してクリックします 仕上げ 配布を設定します。

4.3 ステップ2: 出版物を作成する

ディストリビューションを構成した後、次の手順では、サブスクライバーにレプリケートされるデータオブジェクトを定義するパブリケーションを作成します。

出版物を作成するには SQL Server Management Studio：

オブジェクトエクスプローラーで、 Replication フォルダにコピーします。
右クリックする 地元の出版物 をクリックして 新しい出版物.
新しい出版物ウィザードtarts;クリック次へウェルカムページ。
公開したいデータベースを 出版物データベース ページ。これにより、選択したデータベースへの公開が自動的に有効になります。
ソフトウェア設定ページで、下図のように パブリケーションタイプ ページで、レプリケーションの種類を選択します。 スナップショットの出版, トランザクション出版物, ピアツーピア出版または 出版物をマージする.
ソフトウェア設定ページで、下図のように記事ページを展開し、 テーブル類 ノードをクリックし、記事として含めるテーブルを選択します。
オプションで展開 ストアドプロシージャ, ビュー、またはその他のオブジェクトタイプを使用して、追加の記事を含めます。
詳しくはこちら 記事のプロパティ フィルタリングやその他の記事固有の設定を構成します。
ソフトウェア設定ページで、下図のように テーブル行のフィルタリング ページで、必要に応じて行フィルターを追加します。
ソフトウェア設定ページで、下図のように スナップショットエージェント ページで、スナップショットをいつ作成するか（即時、特定の時刻、またはスケジュールに従って）を選択します。
ソフトウェア設定ページで、下図のように エージェントのセキュリティ ページで、スナップショットエージェントのセキュリティコンテキストを指定します。
ソフトウェア設定ページで、下図のように ウィザードアクション 出版物を作成する.
出版物名を入力してクリック 仕上げ.

4.4 ステップ3: サブスクリプションの作成

パブリケーションを作成した後の次のステップは、パブリケーションをサブスクライバーデータベースに接続するサブスクリプションを作成することです。

サブスクリプションには、プッシュサブスクリプション（ディストリビューターが管理）とプルサブスクリプション（サブスクライバーが管理）があります。主な違いは、サブスクリプションを作成する場所と、選択するエージェントの場所です。エージェントの場所によって、サブスクリプションのアクション（プッシュまたはプル）が決まります。

プッシュサブスクリプションの場合 （ディストリビューターにより管理）：

ソフトウェア設定ページで、下図のように 出版社 サーバー、拡張 Replication -> 地元の出版物.
出版物を右クリックして選択 新しいサブスクリプション.

プルサブスクリプションの場合 （加入者により管理されます）：

ソフトウェア設定ページで、下図のように 加入者 サーバー、拡張 Replication、右クリック ローカルサブスクリプション、および選択 新しいサブスクリプション.
ソフトウェア設定ページで、下図のように出版ページ、クリック もう完成させ、ワークスペースに掲示しましたか? SQL Server Publisher パブリッシャーサーバーに接続します。

両方のサブスクリプションタイプに共通するウィザードの手順:

新しいサブスクリプションウィザードで、次へウェルカムページ。
出版物を選択してクリック次へ.
ソフトウェア設定ページで、下図のように 販売代理店の所在地 ページでエージェントの場所を選択します。
- プッシュサブスクリプション: 「ディストリビューターですべてのエージェントを実行する」を選択します。ディストリビューターはサブスクライバーに変更をプッシュします。
- プルサブスクリプション: 「各エージェントをサブスクライバーで実行する」を選択します。各サブスクライバーはディストリビューターから変更をプルします。
ソフトウェア設定ページで、下図のように 登録者 ページで、既存の加入者サーバーを選択するか、 サブスクライバを追加 新しいものを追加します。
サブスクライバーごとに、宛先データベースを選択するか、新しいデータベースを作成します。 メモ: サブスクリプションデータベースは、同じものを使用している場合でも、パブリッシャーデータベースとは異なる必要があります。 SQL Server インスタンス。
ソフトウェア設定ページで、下図のように 配布エージェントのセキュリティ ページで、各サブスクリプションのプロパティボタンをクリックして、セキュリティコンテキストを構成します。
ソフトウェア設定ページで、下図のように 同期スケジュール ページで、継続的な同期またはスケジュールされた同期を選択します。
ソフトウェア設定ページで、下図のように サブスクリプションの初期化 すぐに ウィザードの完了時に初期化するか、 最初の同期.
ウィザードのアクションを確認してクリック 仕上げ.

5. 監視と管理 SQL Server Replication

5.1 レプリケーションモニターによるレプリケーションの監視

レプリケーションモニターを起動するには:

In SQL Server 管理スタジオ、展開 Replication オブジェクトエクスプローラーで。
右クリックする Replication をクリックして レプリケーションモニターを起動する.
出版社が登録されていない場合は、 パブリッシャーを追加 左ペインに表示されます。
選択する 追加 SQL Server Publisher パブリッシャーサーバーに接続します。
パブリッシャーは、パブリケーションとサブスクリプションの展開可能なノードとともに左側のペインに表示されます。

5.2 パフォーマンス監視

5.2.1 モニターのレイテンシ

レプリケーションのレイテンシとは、パブリッシャー側で変更が発生してからサブスクライバー側でその変更が適用されるまでの時間差です。レイテンシを監視して、データの鮮度がビジネス要件を満たしていることを確認してください。

レプリケーションモニターを使用して、「すべてのサブスクリプション」タブでレイテンシメトリックを確認します。「レイテンシ」列には平均レイテンシ（秒単位）が表示されます。トランザクションレプリケーションの場合、トレーサートークンは、レプリケーションパイプラインを通じて追跡されるマーカートランザクションを挿入することで、正確なレイテンシ測定を提供します。

トレーサートークンを使用するには:

レプリケーションモニターで、トランザクションパブリケーションを選択します。
クリック トレーサートークン タブには何も表示されないことに注意してください。
詳しくはこちら トレーサーを挿入 マーカートランザクションを挿入します。
トークンがパブリッシャーからディストリビューター、そしてサブスクライバーへと移動する様子を監視します。
各セグメントにかかる時間を表示してボトルネックを特定します。

5.2.2 スループットの監視

スループットは、時間の経過とともに複製されるデータの量を測定し、通常は1秒あたりのトランザクション数または1秒あたりのコマンド数で表されます。スループットを監視して、レプリケーションがパブリッシャーのアクティビティに対応していることを確認します。

レプリケーションモニターは基本的な同期ステータスを提供しますが、配信率や詳細なスループット指標はGUIでは表示されません。スループットを監視するには、ディストリビューションデータベースに対してT-SQLクエリを使用します。

USE distribution
GO

-- Direct join to avoid subquery
SELECT TOP 20
    h.time AS [Time],
    a.name AS [Agent Name],
    h.runstatus AS [Status],
    h.delivered_transactions AS [Delivered Transactions],
    h.delivered_commands AS [Delivered Commands],
    h.delivery_rate AS [Delivery Rate (commands/sec)],
    h.delivery_latency AS [Delivery Latency (ms)],
    h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO

ステータスコード: 1 = Start、2 = 進行中、3 = 成功、4 = アイドル、5 = 再試行、6 = 失敗。配信レートとパブリッシャーのトランザクションレートを比較して、レプリケーションが遅れている状況を特定します。 Windowsパフォーマンスモニター各レプリケーションエージェントに追加のスループットメトリックを提供します。

5.2.3 ボトルネックの特定

レプリケーションのボトルネックは、トポロジ内の複数のポイントで発生する可能性があります。パブリッシャー側では、スナップショット生成に長時間かかったり、ログリーダーエージェントの遅延が発生したりする場合、リソースの制約が考えられます。レプリケーション処理中は、パブリッシャー側のCPU、メモリ、ディスクI/Oを監視してください。

ディストリビューター側では、ディストリビューションデータベースに蓄積されたトランザクションがないか確認してください。未配信のコマンドが多数ある場合は、ディストリビューターが配信に対応できていないことを示しています。ディストリビューターサーバーのリソースを監視し、大量のトランザクションを処理する場合は専用のリモートディストリビューターの使用を検討してください。

サブスクライバー側では、リソース不足、インデックスの欠落、または挿入操作を遅らせる制約などにより、変更の適用が遅くなる可能性があります。ディストリビューションエージェントの実行中は、サブスクライバーのリソース使用率とクエリパフォーマンスを監視してください。コンポーネント間のネットワーク帯域幅の制限も、特にデータ量が多い場合にはボトルネックの原因となります。

5.3 レプリケーションエージェントの管理

5.3.1 Startおよび停止エージェント

にtarレプリケーションエージェントを停止または変更します。

In SQL Server 管理スタジオ、展開 SQL Server エージェント -> 求人.
レプリケーションエージェントジョブを見つけます (名前には通常、パブリケーションとサブスクライバーの情報が含まれます)。
ジョブを右クリックして選択 Start ジョブ or ジョブを停止.

5.3.2 エージェントプロファイルの設定

エージェントプロファイルには、エージェントの動作を制御するパラメーターセットが含まれています。 SQL Server 一般的なシナリオに最適化されたデフォルトのプロファイルが提供されており、特定のニーズに合わせてカスタムプロファイルを作成することもできます。

エージェントプロファイルを変更するには:

オブジェクトエクスプローラーで展開 Replication.
右クリックする Replication をクリックして ディストリビューターのプロパティ.
クリック プロファイルのデフォルト
ドロップダウンからエージェントの種類 (スナップショット、ログリーダー、ディストリビューション、またはマージ) を選択します。
プロフィールを選択してクリック特性パラメータ値を表示します。
詳しくはこちら 新しいプロフィール 既存のプロファイルに基づいてカスタムプロファイルを作成します。
必要に応じてパラメータを変更し、クリックします OK.

サブスクリプションのプロパティを編集し、エージェントプロファイルドロップダウンから目的のプロファイルを選択して、エージェントにプロファイルを適用します。

5.3.3 エージェントのパラメータと設定

エージェントパラメータはパフォーマンスと動作を微調整します。ディストリビューションエージェントの主なパラメータには、CommitBatchSize（コミットごとに適用されるトランザクション数）、CommitBatchThreshold（コミット前のコマンド数）、SubscriptionStreams（高速配信のための並列接続）、QueryTimeout（コマンドのタイムアウト）などがあります。

ログリーダーエージェントの重要なパラメータには、ReadBatchSize（スキャンごとに読み取るトランザクション数）、ReadBatchThreshold（配信前のコマンド数）、PollingInterval（ログスキャン間の遅延）などがあります。これらのパラメータは、トランザクション量とレイテンシ要件に応じて調整してください。

5.4 バックアップと復元に関する考慮事項

レプリケーションに関係するデータベースのバックアップには特別な考慮が必要です。パブリッシャーデータベースについては、定期的な完全バックアップとトランザクションログバックアップが不可欠です。トランザクションレプリケーションでデータベースをバックアップする際は、WITH REPLICATION オプションを使用して、データベースのバックアップをレプリケーション対応としてマークしてください。レプリケーション構成を保護するため、ディストリビューションデータベースは定期的にバックアップしてください。

パブリッシャーデータベースを同じサーバーに同じ名前で復元する場合は、WITH KEEP_REPLICATION オプションを使用してレプリケーション状態を保持します。このオプションにより、ログリーダーエージェントによってまだ処理されていないトランザクションはレプリケーション対象としてマークされたままになり、サブスクリプションを再初期化することなくレプリケーションが自動的に続行されます。

バックアップが利用できない、破損している、またはデータベースファイルが破損している災害復旧シナリオでは、専用の復旧ツールが必要になる場合があります。 DataNumen SQL Recovery 破損した、またはアクセスできない MDF および NDF ファイルからデータを抽出できるため、標準的な復元手順が失敗した場合の最後の手段となります。

の詳細について SQL Server バックアップについては、総合ガイド.

6. よくある質問 (FAQ)

Q: スナップショットとトランザクションレプリケーションの違いは何ですか?

A: スナップショットレプリケーションは、特定の時点におけるデータの完全なコピーを取得し、それをサブスクライバーに適用します。これは、頻繁に変更されないデータに適しています。トランザクションレプリケーションは、tar初期スナップショットを使用してトランザクションを実行し、個々のトランザクションが発生するたびに継続的に複製することで、頻繁に変更されるデータのほぼリアルタイムの同期を実現します。

Q: 異なる SQL Server バージョン？

A：はい。 SQL Server レプリケーションは、限られた範囲内でバージョン互換性をサポートします。ディストリビュータのバージョンはパブリッシャーのバージョンと同等かそれ以上である必要があり、サブスクライバのバージョンはパブリッシャーのバージョンの2つ以内であれば問題ありません。例えば、パブリッシャーが SQL Server 2016年、加入者は SQL Server 2012、2014、2016、2017、または 2019。

Q: マージレプリケーションで競合を処理するにはどうすればよいですか?

A: マージレプリケーションには、組み込みの競合検出および解決メカニズムが備わっています。アーティクルレベルで競合解決機能を設定することができ、組み込みの競合解決機能を選択するか、カスタム競合解決機能を実装できます。競合は通常、優先度ベースまたはタイムスタンプベースの方法で解決されます。また、手動で確認できるように競合をログに記録することもできます。

Q: レプリケーションはパフォーマンスにどのような影響を与えますか?

A: レプリケーションはパフォーマンスにいくつかの影響を与えます。パブリッシャーは変更の追跡とスナップショットの生成によるオーバーヘッドを経験し、ディストリビューターはトランザクションの保存と転送にリソースを使用し、データ転送時にはネットワーク帯域幅が消費されます。影響はレプリケーションの種類によって異なります。スナップショットレプリケーションは定期的に大きな負荷のバーストを引き起こしますが、トランザクションレプリケーションはより一貫性がありながらも継続的な負荷を維持します。

Q: レプリケーショントポロジをセキュリティで保護するにはどうすればよいですか?

A: レプリケーショントポロジーを保護するには、Windows認証や強力な認証を使用するなど、いくつかのベストプラクティスを実装します。 SQL Server 認証、TLSを使用した接続の暗号化、適切な方法でスナップショットフォルダを保護する NTFS 権限を設定し、アクセスを制御するためにパブリケーションアクセスリスト (PAL) を構成し、各レプリケーションエージェントに必要な最小限の権限を持つ個別のサービスアカウントを使用し、レプリケーションセキュリティ設定を定期的に監査します。

Q: Azure SQL Database にレプリケートできますか?

A: はい、オンプレミスのトランザクションレプリケーションを使用してAzure SQL Databaseにレプリケートできます。 SQL Server または、Azure SQL Managed Instance をパブリッシャーおよびディストリビューターとして使用します。Azure SQL Database はサブスクライバーとして機能することはできますが、パブリッシャーまたはディストリビューターとして機能することはできません。マージレプリケーションとピアツーピアレプリケーションは、Azure SQL Database ではサポートされていません。

Q: レプリケーションラグを監視するにはどうすればよいですか?

A: レプリケーションモニターを使用してレプリケーション遅延を監視します。 SQL Server Management Studio では、各サブスクリプションの待機時間メトリックが表示されます。また、MSdistribution_history や MSrepl_commands などのディストリビューションデータベーステーブルをクエリしたり、レプリケーションエージェント固有のパフォーマンスカウンターを使用したり、待機時間しきい値に基づいてアラートを設定したりすることで、同期の遅延をプロアクティブに検出して対処することもできます。

Q: 加入者がオフラインになるとどうなりますか?

A: サブスクライバーがオフラインの場合、動作はレプリケーションの種類によって異なります。トランザクションレプリケーションの場合、トランザクションはサブスクライバーがオンラインに戻るまでディストリビューションデータベースに蓄積され、その後同期が再開されます。マージレプリケーションの場合、変更は両側で追跡され、接続が回復するとマージされます。保持期間の設定によって、データの再初期化が必要になるまでの保持期間が決まります。

Q: 既存の出版物に新しい記事を追加するにはどうすればよいですか?

A: 既存の出版物に新しい記事を追加するには、 SQL Server Management Studioを使用してパブリケーションのプロパティを変更し、追加のオブジェクトを選択するか、sp_addarticleストアドプロシージャを使用してください。記事を追加した後は、新しいスナップショットを生成し、すべてのサブスクリプションを再初期化して、サブスクライバーが新しい記事を確実に受信できるようにします。パブリケーションの設定によっては、変更内容によってはサブスクリプションの再初期化が必要になる場合があります。

Q: データベースからレプリケーションを削除するにはどうすればよいですか?

A: データベースからレプリケーションを削除するには、まずsp_dropsubscriptionを使用してすべてのサブスクリプションを削除し、次にsp_droppublicationを使用してパブリケーションを削除し、最後にsp_replicationdboptionを使用してデータベースのパブリッシングを無効にします。サーバーがディストリビューターの場合は、sp_dropdistributorを使用してディストリビューションを無効にします。レプリケーション設定を削除する前に、必ずデータベースをバックアップしてください。

Q：違いは何ですか SQL Server レプリケーションと AlwaysOn 可用性グループ?

A: レプリケーションはオブジェクトレベルで動作するデータ分散および統合ソリューションです。 Always On 可用性グループデータベースレベルで動作する高可用性および災害復旧ソリューションです。

7. 結論

SQL Server レプリケーションは、複数のデータベースや場所にデータを分散・同期するための堅牢なフレームワークを提供します。このテクノロジーは、様々なレプリケーションタイプを通じて、様々なシナリオをサポートします。

適切なレプリケーション戦略の選択は、お客様の具体的な要件によって異なります。データの変更頻度、レイテンシ要件、サブスクライバーによる更新の必要性、ネットワーク特性、サブスクライバーの自律性要件などを考慮してください。スナップショットレプリケーションは、レイテンシが重要ではない、変更頻度の低い参照データに最適です。トランザクションレプリケーションは、低レイテンシで主に一方向のデータフローを必要とする大規模なシナリオに適しています。

サブスクライバーがオフライン機能と双方向同期による自律的な操作を必要とする場合は、マージレプリケーションを選択してください。ピアツーピアレプリケーションを実装することで、複数のアクティブノード間で読み取り操作の負荷分散を行い、ほぼリアルタイムの一貫性を維持できます。多様な要件を持つ複雑なシナリオでは、複数のレプリケーションタイプを組み合わせたハイブリッドアプローチを検討してください。

参考情報

著者について

袁勝 10年以上の経験を持つ上級データベース管理者（DBA）です。 SQL Server 環境およびエンタープライズデータベース管理に精通しており、金融サービス、医療、製造業など、様々な組織において数百件のデータベース復旧シナリオを解決してきました。

ユアンの専門は SQL Server データベースの復旧、高可用性ソリューション、パフォーマンス最適化など、幅広い分野に精通しています。彼は、マルチテラバイト規模のデータベースの管理、Always On可用性グループの実装、ミッションクリティカルなビジネスシステム向けの自動バックアップおよび復旧戦略の開発など、豊富な実務経験を有しています。

Yuanは、技術的な専門知識と実践的なアプローチを通じて、データベース管理者やITプロフェッショナルが複雑な問題を解決するのに役立つ包括的なガイドの作成に重点を置いています。 SQL Server 効率的に課題に取り組みます。常に最新の SQL Server リリースと Microsoft の進化するデータベーステクノロジを活用し、定期的にリカバリシナリオをテストして、推奨事項が実際のベストプラクティスを反映していることを確認します。

について質問があります SQL Server 回復または追加のデータベーストラブルシューティングガイダンスが必要ですか？Yuanは歓迎しますフィードバックと提案これらの技術リソースを改善するためです。