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

適用対象: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse APPLIES TO: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

一般にトランザクション レプリケーションは、パブリケーションのデータベース オブジェクトとデータのスナップショットで開始されます。Transactional replication typically starts with a snapshot of the publication database objects and data. 最初のスナップショットが取得されるとすぐ、それ以後パブリッシャーでデータやスキーマが変更されると、通常はその都度 (ほぼリアルタイムで) サブスクライバーに配信されるようになります。As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time). データの変更は、パブリッシャーで発生したのと同じ順序で、同じトランザクションの中で、サブスクライバーに適用されます。したがって、パブリケーション内では、トランザクションの一貫性が保証されます。The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher; therefore, within a publication, transactional consistency is guaranteed.

トランザクション レプリケーションは一般にサーバー間の環境で使用され、次のような場合に適しています。Transactional replication is typically used in server-to-server environments and is appropriate in each of the following cases:

  • 増分変更をその都度サブスクライバーに反映する場合。You want incremental changes to be propagated to Subscribers as they occur.

  • アプリケーションで、パブリッシャーでの変更をサブスクライバーに反映するまでの待機時間を短くする必要がある場合。The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber.

  • アプリケーションで中間状態のデータにアクセスする必要がある場合。The application requires access to intermediate data states. たとえば行が 5 回変更された場合、トランザクション レプリケーションでは、その行の最終的な変更結果だけでなく、それぞれの変更にアプリケーションで応答すること (トリガーを起動するなど) ができます。For example, if a row changes five times, transactional replication allows an application to respond to each change (such as firing a trigger), not simply the net data change to the row.

  • パブリッシャーで大量の挿入、更新、および削除が行われる場合。The Publisher has a very high volume of insert, update, and delete activity.

  • パブリッシャーまたはサブスクライバーがSQL ServerSQL Server 以外のデータベース (Oracle など) である場合。The Publisher or Subscriber is a non-SQL ServerSQL Server database, such as Oracle.

既定では、変更はパブリッシャーには反映されないため、トランザクション パブリケーションに対するサブスクライバーは読み取り専用として処理されます。By default, Subscribers to transactional publications should be treated as read-only, because changes are not propagated back to the Publisher. ただし、サブスクライバーでの更新を許可するオプションも用意されています。However, transactional replication does offer options that allow updates at the Subscriber.

注意

Azure SQL Database マネージド インスタンスは、スナップショットおよびトランザクション レプリケーションのパブリッシャー、ディストリビューター、およびサブスクライバーの可能性があります。Azure SQL Database managed instance can be a publisher, distributor, and subscriber for snapshot and transactional replication. Azure SQL Database のシングル データベースとプール データベースは、スナップショットとトランザクション レプリケーションのプッシュ サブスクライバーの可能性しかありません。Azure SQL database single and pooled databases can only be push subscribers for snapshot and transactional replication. 詳細については、Azure SQL Database を使用したトランザクションのレプリケーションに関する記事を参照してください。For more information, see Transactional replication with Azure SQL Database.

トランザクション レプリケーションの動作方法How Transactional Replication Works

トランザクション レプリケーションは、 SQL ServerSQL Server のスナップショット エージェント、ログ リーダー エージェント、およびディストリビューション エージェントによって実装されます。Transactional replication is implemented by the SQL ServerSQL Server Snapshot Agent, Log Reader Agent, and Distribution Agent. スナップショット エージェントは、パブリッシュされたテーブルやデータベース オブジェクトのスキーマとデータを含むスナップショット ファイルを作成し、ファイルをスナップショット フォルダーに格納して、同期ジョブをディストリビューターのディストリビューション データベースに記録します。The Snapshot Agent prepares snapshot files containing schema and data of published tables and database objects, stores the files in the snapshot folder, and records synchronization jobs in the distribution database on the Distributor.

ログ リーダー エージェントは、トランザクション レプリケーション用に構成した各データベースのトランザクション ログを監視し、レプリケーションのマークが付けられたトランザクションをトランザクション ログから、信頼性の高いストア アンド フォワード キューとして機能するディストリビューション データベースにコピーします。The Log Reader Agent monitors the transaction log of each database configured for transactional replication and copies the transactions marked for replication from the transaction log into the distribution database, which acts as a reliable store-and-forward queue. ディストリビューション エージェントは、スナップショット フォルダーからの初期スナップショット ファイルと、ディストリビューション データベース テーブルに保持されているトランザクションをサブスクライバーにコピーします。The Distribution Agent copies the initial snapshot files from the snapshot folder and the transactions held in the distribution database tables to Subscribers.

パブリッシャーでの増分変更は、待機時間が最小となるように連続実行できるディストリビューション エージェントのスケジュールに従って、またはスケジュールされた間隔で、サブスクライバーに送られます。Incremental changes made at the Publisher flow to Subscribers according to the schedule of the Distribution Agent, which can run continuously for minimal latency, or at scheduled intervals. 即時更新オプションまたはキュー更新オプションなしでトランザクション レプリケーションを使用する場合、データはパブリッシャーで変更されるため、更新の競合は回避されます。Because changes to the data must be made at the Publisher (when transactional replication is used without immediate updating or queued updating options), update conflicts are avoided. 最終的には、すべてのサブスクライバーがパブリッシャーと同じ値になります。Ultimately, all Subscribers will achieve the same values as the Publisher. 即時更新オプションまたはキュー更新オプションをトランザクション レプリケーションで使用する場合、更新はサブスクライバーで行われます。キュー更新の場合、競合が発生する可能性があります。If immediate updating or queued updating options are used with transactional replication, updates can be made at the Subscriber, and with queued updating, conflicts might occur.

次の図に、トランザクション レプリケーションの主要なコンポーネントを示します。The following illustration shows the principal components of transactional replication.

トランザクション レプリケーション コンポーネントとデータ フローTransactional replication components and data flow

初期データセットInitial Dataset

新しいトランザクション レプリケーションでパブリッシャーから増分変更を受信する前に、サブスクライバーは、パブリッシャーのテーブルと同じスキーマおよびデータを持つテーブルを格納する必要があります。Before a new transactional replication Subscriber can receive incremental changes from a Publisher, the Subscriber must contain tables with the same schema and data as the tables at the Publisher. 初期データセットは、通常、スナップショット エージェントにより作成され、ディストリビューション エージェントにより配信および適用されるスナップショットです。The initial dataset is typically a snapshot that is created by the Snapshot Agent and distributed and applied by the Distribution Agent. 初期データセットは、バックアップや、 SQL ServerSQL Server Integration Services などでも提供されます。The initial dataset can also be supplied through a backup or other means, such as SQL ServerSQL Server Integration Services.

スナップショットがサブスクライバーに配信および適用されると、初期スナップショットを待っているサブスクライバーだけが影響を受けます。When snapshots are distributed and applied to Subscribers, only those Subscribers waiting for initial snapshots are affected. そのパブリケーションに対するその他のサブスクライバー (既に初期化済みのもの) は影響を受けません。Other Subscribers to that publication (those that have already been initialized) are unaffected.

同時実行スナップショット処理Concurrent Snapshot Processing

スナップショット レプリケーションは、スナップショット生成中にレプリケーションの一部としてパブリッシュされたすべてのテーブルに、共有ロックをかけます。Snapshot replication places shared locks on all tables published as part of replication for the duration of snapshot generation. これにより、パブリッシュ テーブルで更新が行われることが防止されます。This can prevent updates from being made on the publishing tables. トランザクション レプリケーションでの既定である、同時実行スナップショット処理では、スナップショットの生成中に共有ロックが設定されることはありません。ユーザーはレプリケーションが初期スナップショット ファイルを作成している間も作業を継続できます。Concurrent snapshot processing, the default with transactional replication, does not hold the share locks in place during the entire snapshot generation, which allows users to continue working uninterrupted while replication creates initial snapshot files.

スナップショット エージェントSnapshot Agent

スナップショット エージェントがトランザクション レプリケーションで初期スナップショットを実装する手順はスナップショット レプリケーションと同じです (ただし、上記の同時実行スナップショット処理に該当する部分は除きます)。The procedures by which the Snapshot Agent implements the initial snapshot in transactional replication are the same procedures used in snapshot replication (except as outlined above with regard to concurrent snapshot processing).

スナップショット ファイルが作成されると、 MicrosoftMicrosoft Windows エクスプローラーを使用してスナップショット フォルダー内のそれらのファイルを参照できます。After the snapshot files have been generated, you can view them in the snapshot folder using MicrosoftMicrosoft Windows Explorer.

データの変更およびログ リーダー エージェントModifying Data and the Log Reader Agent

ログ リーダー エージェントはディストリビューターで実行されます。通常は連続実行されますが、設定したスケジュールに従って実行することもできます。The Log Reader Agent runs at the Distributor; it typically runs continuously, but can also run according to a schedule you establish. ログ リーダー エージェントを実行すると、パブリケーション トランザクション ログ (通常の SQL ServerSQL Server データベース エンジン動作時にトランザクションの追跡と復旧に使用するものと同じデータベース ログ) の読み取り後、レプリケーション用にマークが付けられているトランザクション内のデータに対する INSERT、UPDATE、DELETE ステートメントなどの変更が識別されます。When executing, the Log Reader Agent first reads the publication transaction log (the same database log used for transaction tracking and recovery during regular SQL ServerSQL Server Database Engine operations) and identifies any INSERT, UPDATE, and DELETE statements, or other modifications made to the data in transactions that have been marked for replication. 次に、それらのトランザクションが、ディストリビューターのディストリビューション データベースにバッチでコピーされます。Next, the agent copies those transactions in batches to the distribution database at the Distributor. ログ リーダー エージェントでは、内部ストアド プロシージャ sp_replcmds を使用して、レプリケーション用にマークを付けたコマンドの次のセットをログから取得します。The Log Reader Agent uses the internal stored procedure sp_replcmds to get the next set of commands marked for replication from the log. ディストリビューション データベースは、ストア アンド フォワード キューになります。ここから、変更をサブスクライバーに送信します。The distribution database then becomes the store-and-forward queue from which changes are sent to Subscribers. コミットされたトランザクションだけがディストリビューション データベースに送信されます。Only committed transactions are sent to the distribution database.

トランザクションのバッチ全体がディストリビューション データベースに正常に書き込まれるとコミットされます。After the entire batch of transactions has been written successfully to the distribution database, it is committed. ログ リーダー エージェントは、ディストリビューターへのコマンドの各バッチがコミットされた後で、 sp_repldone を呼び出して、レプリケーションが最後に完了した日付をマークします。Following the commit of each batch of commands to the Distributor, the Log Reader Agent calls sp_repldone to mark where replication was last completed. 最後に、ログ リーダー エージェントは、トランザクション ログ内の削除する行をマークします。Finally, the agent marks the rows in the transaction log that are ready to be purged. レプリケートされるのを待機している行は、削除されません。Rows still waiting to be replicated are not purged.

トランザクション コマンドは、すべてのサブスクライバーに反映されるまで、または、最大ディストリビューション保有期間に達するまで、ディストリビューション データベースに保持されます。Transaction commands are stored in the distribution database until they are propagated to all Subscribers or until the maximum distribution retention period has been reached. サブスクライバーは、トランザクションがパブリッシャーで適用されたときと同じ順序でトランザクションを受信します。Subscribers receive transactions in the same order in which they were applied at the Publisher.

ディストリビューション エージェントDistribution Agent

ディストリビューション エージェントは、プッシュ サブスクリプションのディストリビューターと、プル サブスクリプションのサブスクライバーで動作します。The Distribution Agent runs at the Distributor for push subscriptions and at the Subscriber for pull subscriptions. エージェントは、トランザクションをディストリビューション データベースからサブスクライバーに移動します。The agent moves transactions from the distribution database to the Subscriber. サブスクリプションが検証対象としてマークされている場合、ディストリビューション エージェントは、パブリッシャーのデータとサブスクライバーのデータが一致しているかどうかも確認します。If a subscription is marked for validation, the Distribution Agent also checks whether data at the Publisher and Subscriber match.

パブリケーションの種類Publication types

トランザクション レプリケーションでは、以下の 4 種類のパブリケーションが提供されます。Transactional replication offers four publication types:

[パブリケーションの種類]Publication Type 説明Description
標準トランザクション パブリケーションStandard transactional publication サブスクライバーのデータがすべて読み取り専用であるトポロジに適したパブリケーションです (トランザクション レプリケーションでは、このパブリケーションがサブスクライバーで強制されるわけではありません)。Appropriate for topologies in which all data at the Subscriber is read-only (transactional replication does not enforce this at the Subscriber).

Transact-SQL またはレプリケーション管理オブジェクト (RMO) を使用する場合、標準トランザクション パブリケーションが既定で作成されます。Standard transactional publications are created by default when using Transact-SQL or Replication Management Objects (RMO). パブリケーションの新規作成ウィザードを使用する場合、 [パブリケーションの種類] ページで [トランザクション パブリケーション] を選択すると、標準トランザクション パブリケーションが作成されます。When using the New Publication Wizard, they are created by selecting Transactional publication on the Publication Type page.

パブリケーションの作成の詳細については、「データとデータベース オブジェクトのパブリッシュ」を参照してください。For more information about creating publications, see Publish Data and Database Objects.
更新可能なサブスクリプションを含むトランザクション パブリケーションTransactional publication with updatable subscriptions このパブリケーションの特徴として以下が挙げられます。The characteristics of this publication type are:

-各場所には同一のデータが格納され、パブリッシャーとサブスクライバーが 1 つずつ含まれます。-Each location has identical data, with one Publisher and one Subscriber.
-サブスクライバーで行を更新することができます。-It is possible to update rows at the Subscriber
-これは、高可用性および読み取りのスケーラビリティが求められるサーバー環境に最適なトポロジです。-This topology is best suited for server environments requiring high availability and read scalability.

詳細については、「更新可能なサブスクリプション」を参照してください。For more information, see Updatable Subscriptions.
ピア ツー ピア トポロジPeer-to-peer topology このパブリケーションの特徴として以下が挙げられます。The characteristics of this publication type are:
-各場所には同一のデータが格納され、パブリッシャーおよびサブスクライバーの両方の役割を果たします。- Each location has identical data and acts as both a Publisher and Subscriber.
-同一の行は一度に 1 つの場所でのみ変更できます。- The same row can be changed only at one location at a time.
-競合検出をサポートします。- Supports conflict detection
-これは、高可用性および読み取りのスケーラビリティが求められるサーバー環境に最適なトポロジです。- This topology is best suited for server environments requiring high availability and read scalability.

詳細については、「ピア ツー ピア トランザクション レプリケーション」を参照してください。For more information, see Peer-to-Peer Transactional Replication.
双方向トランザクション レプリケーションBidirectional transactional replication このパブリケーションの特徴として以下が挙げられます。The characteristics of this publication type are:
双方向レプリケーションは、ピア ツー ピア レプリケーションに似ています、ただし、競合の解決は提供されません。Bidirectional replication is similar to Peer-to-Peer replication, however, it does not provide conflict resolution. また、双方向レプリケーションは、2 台のサーバーに制限されます。Additionally, bidirectional replication is limited to 2 servers.

詳細については、「双方向トランザクション レプリケーション」を参照してください。For more information, see Bidirectional Transactional Replication