Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
データベース管理者は複数サーバーへデータを配信し、レポーティング負荷を分散、地理的に分散したアプリケーションのデータ可用性を高めるため、SQL Serverレプリケーションを活用するケースが多く見られます。しかしレプリケーションは「高可用性ソリューション」または「バックアップ」と混同されやすく、不適切なアーキテクチャ設計につながることが少なくありません。
本ガイドではSQL Serverレプリケーションの仕組み、各種レプリケーション方式、実務での活用事例、アーキテクチャ構成要素、制限事項を解説します。また、Always On可用性グループやバックアップソリューションとの比較も紹介します。
SQL Serverレプリケーションは、プライマリSQL Serverデータベース（パブリッシャー）のデータをコピー・同期し、1つ以上のセカンダリデータベース（サブスクライバー）へ配信する仕組みです。複数のデータベースサーバー間、または同一サーバー内でデータの整合性と可用性を確保する一般的な手法となります。
SQL Serverレプリケーションの代表的な活用事例：
バックアップソリューションとは異なり、レプリケーションは「復旧」や「過去データの保管」ではなく、データの配信・同期を目的としています。
SQL Serverレプリケーションの動作概要
本機能は相互に連携する複数のコンポーネントで構成されます。
SQL Serverには主に3種類のレプリケーションが用意されており、それぞれ業務ニーズに応じて使い分けます。
最もシンプルな方式です。指定した時点のパブリケーション内の全オブジェクト・データの完全なコピーを作成し、その「スナップショット」をサブスクライバーへ配信します。
仕組み：スナップショットエージェントがスキーマとデータファイルを作成し、ディストリビューションエージェントがファイルをサブスクライバーへ転送し一括適用します。
事例：小売企業が夜間に1回、支店サーバーの商品カタログデータを更新する運用。
遅延：大きい（定時実行が基本で、日次または週次で実施）。
推奨利用シナリオ：
メリット：
デメリット：
リアルタイムまたは準リアルタイムでデータ配信を行う際に標準的に利用される方式です。パブリッシャーでデータ変更が発生すると、トランザクションログを経由し速やかにサブスクライバーへ伝播します。
仕組み：パブリッシャーのトランザクションログを読み取り、ログリーダーエージェントがレプリケーション対象の変更（INSERT、UPDATE、DELETE）を抽出しディストリビューターへ送信。ディストリビューションエージェントがトランザクションを順次サブスクライバーに適用します。
事例：金融企業が本番SQL Serverのレポートクエリを専用レポートサーバーへオフロードするために活用。
遅延：非常に小さい（準リアルタイムなデータ整合性）。
推奨利用シナリオ：
パブリッシャーとサブスクライバーがネットワーク切断状態でも独立してデータ更新を行うユースケース向けに設計された方式です。
仕組み：トリガーとメタデータテーブルでデータ変更を追跡。通信が復旧したタイミングでマージエージェントがルール・優先順位に基づき変更内容を同期し、発生した競合を解決します。
事例：外勤営業アプリ。リモートの従業員がローカルで顧客情報を更新し、ネット接続時に変更を一括同期する運用。
遅延：可変（接続頻度に依存）。
推奨利用シナリオ：
メリット：
デメリット：
スナップショット / トランザクション / マージレプリケーション比較表
|
レプリケーション種別 |
適切な利用シナリオ |
遅延 |
複雑度 |
|
トランザクションレプリケーション |
レポーティング、リアルタイム同期 |
小 |
中 |
|
スナップショットレプリケーション |
小規模または更新頻度の低いデータセット |
大 |
低 |
|
マージレプリケーション |
リモート・オフライン環境 |
中 |
高 |
最も多い誤解の一つが「レプリケーションで完全な高可用性を実現できる」という認識です。
実際には不可能です。SQL Server Always On可用性グループとレプリケーションは解決する課題が異なります。
|
項目 |
レプリケーション |
Always On可用性グループ |
|
主な目的 |
データ配信 |
高可用性 |
|
自動フェイルオーバー |
非対応 |
対応 |
|
レポート負荷のオフロード |
対応 |
対応 |
|
災害復旧 |
限定的 |
強力にサポート |
|
リアルタイム同期 |
対応 |
対応 |
|
読み取り可能なセカンダリDB |
対応 |
対応 |
|
データフィルタリング |
サポート |
制限あり |
|
異バージョン間の柔軟性 |
優れる |
制約が多い |
|
運用複雑度 |
中 |
高 |
根本的な違い：
アーキテクチャを設計する上で最も重要な考え方の一つです。
レプリケーションはバックアップの代替にはなりません。
レプリケーションがバックアップを代替できない理由：
|
レプリケーション |
バックアップ |
|
データ破損も伝播する |
データ復旧を実現可能 |
|
誤ったDELETE操作も配信される |
任意時点へのリストアが可能 |
|
現在の状態のみ保持 |
過去のデータ世代を保管 |
|
可用性を主目的 |
障害からの復旧を主目的 |
例：
このため、レプリケーションを導入している環境でも、専用のバックアップ・災害復旧施策を別途構築する必要があります。
レプリケーションは強力な機能ですが、運用上の複雑さを伴います。
1. トラブルシューティングが難しい
DBAが頻繁に遭遇する課題は下記の通りです。
海外のSQL Serverコミュニティでも、レプリケーションの障害調査はSQL Server運用の中で難易度の高い作業の一つと認識されています。
2. スキーマ変更の対応が複雑
レプリケーション対象テーブルの構造変更を実施する際、次の作業が必要になる場合があります。
計画の不十分なスキーマ変更はレプリケーションを停止させる恐れがあります。
3. レプリケーション遅延の発生
巨大なトランザクション、ネットワーク輻輳、ディストリビューターのリソース逼迫は同期遅延を引き起こします。
影響を受ける要素：
4. マージレプリケーションのデータ競合
複数システムが同一行を同時更新すると、マージレプリケーション環境でデータ競合が発生します。競合解消ルールを慎重に設計する必要があります。
Microsoft SQL Serverレプリケーションの導入は単なる設定作業だけではありません。綿密なアーキテクチャ設計、定常的な監視、運用ルールの徹底が不可欠です。設計が不十分なレプリケーション環境は、同期遅延、ディストリビューションDBのボトルネック、原因特定困難な障害を引き起こしやすくなります。
以下は本番環境で活用されている重要なベストプラクティスです。
1. 適切なレプリケーショントポロジーを選択
規模や業務負荷を検討せずレプリケーションを導入することが典型的な失敗事例です。
推奨構成：
2. 可能な限り専用ディストリビューターを利用
本番システムでは、パブリッシャー自身をディストリビューターとして使用しないでください。業務上重要なレプリケーションの場合、ディストリビューターは独立したインフラ要素として扱うべきです。
専用ディストリビューターのメリット：
3. 必要なデータのみレプリケート（過剰なレプリケーションを回避）
一部のテーブルだけ必要なのにデータベース全体をレプリケートする設計ミスが多く存在します。
運用指針：
4. 定期的なバックアップを実施
本記事で繰り返し述べた通り、レプリケーションはバックアップの代替にはなりません。総合的なデータ安全性を確保するため、バックアップソリューションを導入し続ける必要があります。
本章ではレプリケーションの設定を手順通り解説します。
レプリケーション作業を開始する前に権限設定を確認してください。権限不備はレプリケーション障害の最も多い原因です。本番環境ではSQL Serverエージェントアカウントやsysadmin権限ではなく、権限を制限した専用ドメインアカウントの利用が推奨されます。
推奨する権限設定一覧表：
|
エージェント |
実行先 |
推奨権限 |
|
スナップショットエージェント |
パブリッシャー / ディストリビューター |
スナップショット共有フォルダの読み取り・書き込み・変更権限。パブリケーションDBのdb_owner。 |
|
ログリーダーエージェント |
ディストリビューター |
ディストリビューションDBのdb_owner。パブリッシャーのトランザクションログ参照権限。 |
|
ディストリビューションエージェント |
ディストリビューター（プッシュ）またはサブスクライバー（プル） |
PAL（パブリケーションアクセスリスト）メンバー、適切なDBロール。 |
設定の起点となることが多い要素です。パブリッシャーと同一サーバー（ローカルディストリビューター）、または独立した専用サーバー（リモートディストリビューター）に配置可能です。
1. SQL Server管理スタジオ（SSMS）にて、ディストリビューターとして使用するサーバーに接続。
2. レプリケーション → ローカルパブリケーションを右クリック →「ディストリビューションの構成」を選択。
3. ウィザードに従い下記を設定：
1. ローカルパブリケーションを右クリック → 新しいパブリケーションを選択。
2. 配信元となるデータベース（パブリッシャーDB）を選択。
3. レプリケーション種別を選択（例：トランザクションレプリケーション）。
4. レプリケーション対象のDBオブジェクト（アーティクル）を選択（トランザクションレプリケーションの場合、テーブルに主キーが必要）。
5. 一部データのみ配信する場合は行フィルター、列フィルターを設定。
6. スナップショットエージェントのスケジュールとセキュリティアカウントを指定。
1. 作成したパブリケーションを右クリック → 新しいサブスクリプションを選択。
2. プッシュまたはプルサブスクリプションを選択（プッシュは集中管理型、プルは負荷分散型）。
3. サブスクライバーサーバーとサブスクリプション用データベースを指定。
4. ディストリビューションエージェントのセキュリティアカウントと実行スケジュールを設定。
SQL Serverレプリケーションモニターが状態確認の中心ツールとなります。下記の用途で活用します。
特殊事例：Amazon RDS SQL Serverへのレプリケーション ☁️
クラウドのマネージド環境には固有の制約が存在します。Amazon RDS SQL Serverをレプリケーション先とする場合は下記事項を理解する必要があります。
従来のSQL Serverレプリケーションはオンプレミス環境向けの基本的な同期機能を提供します。しかし現代の企業システムでは多くの限界が露呈します。
ログリーダーエージェントがボトルネックとなり、大量トランザクション環境で許容できない遅延が発生する場合があります。またディストリビューションエージェントの処理性能は、ネットワーク帯域とディストリビューターのリソースに大きく依存します。
権限管理、スナップショット共有の維持、不可解なエージェント障害の調査に時間を要し、人為的ミスが発生しやすい傾向があります。
SQL Server標準レプリケーションはSQL Server同士のみ対応します。PostgreSQL、Oracle、Snowflakeなど他DBプラットフォームへ直接レプリケートするには独自のETL開発が必須となります。
Information2（英方ソフト）が開発するi2Streamはシームレスなデータベースレプリケーションソリューションです。SQL Serverから別のSQL Server、またPostgreSQL、Oracle、DB2など40種類以上のプラットフォームへデータをレプリケート可能です。
障害発生時には待機系データベースが瞬時に業務を引き継ぐことができます。
SQL Serverレプリケーションは複数システム間でデータを同期・配信する強力な仕組みとして現在も活用されています。レポーティング用途、高可用性、ハイブリッドクラウド導入など目的に応じ、適切なレプリケーション種別と管理ツールを選択することが重要です。一方、i2Streamを利用することでSQL Server環境のレプリケーションを大幅に簡素化可能で、容易に準リアルタイム同期を構築できます。i2Streamの60日間無料トライアルをお申し込みいただけます。