ログ配布とレプリケーション (SQL Server)Log Shipping and Replication (SQL Server)

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

ログ配布では単一のデータベースの 2 つのコピーを使用します。通常、これらのコピーは異なるコンピューターに配置されます。Log shipping involves two copies of a single database that typically reside on different computers. クライアントが任意の時点において使用できるデータベースのコピーは 1 つだけです。At any given time, only one copy of the database is currently available to clients. このコピーはプライマリ データベースと呼ばれます。This copy is known as the primary database. クライアントがプライマリ データベースに対して加えた更新は、ログ配布によってセカンダリ データベースと呼ばれるもう一方のコピー データベースに適用されます。Updates made by clients to the primary database are propagated by means of log shipping to the other copy of the database, known as the secondary database. プライマリ データベースに対して行われた挿入、更新、および削除はすべてトランザクション ログに記録され、ログ配布によってこのトランザクション ログがセカンダリ データベースに適用されます。Log shipping involves applying the transaction log from every insertion, update, or deletion made on the primary database onto the secondary database.

ログ配布はレプリケーションと組み合わせて使用できます。ログ配布とレプリケーションを併用した場合の動作を以下に示します。Log shipping can be used in conjunction with replication, with the following behavior:

  • ログ配布でフェールオーバーが発生すると、レプリケーションが停止します。Replication does not continue after a log shipping failover. フェールオーバーが発生した場合、レプリケーション エージェントはセカンダリに接続しません。その結果、トランザクションがサブスクライバーにレプリケートされなくなります。If a failover occurs, replication agents do not connect to the secondary, so transactions are not replicated to Subscribers. プライマリへのフェールバックが行われると、レプリケーションが再開されます。If a failback to the primary occurs, replication resumes. ログ配布によってセカンダリからプライマリにコピーされたすべてのトランザクションがサブスクライバーにレプリケートされます。All transactions that log shipping copies from the secondary back to the primary are replicated to Subscribers.

  • プライマリが完全に失われた場合、セカンダリの名前を変更してレプリケーションを継続できます。If the primary is permanently lost, the secondary can be renamed so that replication can continue. このトピックの残りの部分では、こうしたケースを処理する場合の要件と手順について説明します。The remainder of this topic describes the requirements and procedures for handling this case. ログ配布を使用する最も一般的なデータベースであるパブリケーション データベースを例として使用します。ただし、サブスクリプション データベースおよびディストリビューション データベースについても同様の手順を適用できます。The example given is the publication database, which is the most common database to log ship, but a similar process can also be applied to subscription and distribution databases.

レプリケーションを再構成することなく、レプリケーションに関連するデータベースを復元する場合の詳細については、「 レプリケートされたデータベースのバックアップと復元」をご覧ください。For information about recovering databases involved in replication without any need to reconfigure replication, see Back Up and Restore Replicated Databases.

注意

パブリケーション データベースの可用性を提供することが目的の場合は、ログ配布ではなく、データベース ミラーリングを使用することをお勧めします。We recommend using database mirroring, rather than log shipping, to provide availability for the publication database. 詳細については、「 データベース ミラーリングとレプリケーション (SQL Server)」をご覧ください。For more information, see Database Mirroring and Replication (SQL Server).

プライマリが失われた場合にセカンダリからレプリケートを行うための要件と手順Requirements and Procedures for Replicating from the Secondary If the Primary Is Lost

以下の要件および考慮事項に注意してください。Be aware of the following requirements and considerations:

  • プライマリに複数のパブリケーション データベースが格納されている場合、すべてのパブリケーション データベースのログが同一のセカンダリに配布されます。If a primary contains more than one publication database, log ship all of the publication databases to the same secondary.

  • セカンダリ サーバー インスタンスのインストール パスは、プライマリ サーバー インスタンスのインストール パスと同一にする必要があります。The installation path for the secondary server instance must be the same as the primary. セカンダリ サーバー上のユーザー データベースの場所は、プライマリ サーバー上の場所と同一にする必要があります。User database locations on the secondary server must be the same as on the primary.

  • プライマリでサービス マスター キーをバックアップします。Back up the service master key at the primary. このキーはセカンダリで復元されます。This key will be restored at the secondary. 詳細については、「BACKUP SERVICE MASTER KEY (Transact-SQL)」を参照してください。For more information, see BACKUP SERVICE MASTER KEY (Transact-SQL).

  • ログ配布では、データ損失の回避は保障されません。Log shipping does not guarantee against data loss. プライマリ データベースで障害が発生した場合、バックアップされていないデータが失われたり、障害時にバックアップ用のデータが失われる可能性があります。A failure on the primary database can result in the loss of data that has not yet been backed up or for backups that are lost during the failure.

トランザクション レプリケーションのログ配布Log Shipping with Transactional Replication

トランザクション レプリケーションの場合、ログ配布の動作は sync with backup オプションの設定によって異なります。For transactional replication, the behavior of log shipping depends on the sync with backup option. このオプションは、パブリケーション データベースおよびディストリビューション データベースで設定できます。パブリッシャーのログ配布では、パブリケーション データベースでの設定のみが関係します。This option can be set on the publication database and distribution database; in log shipping for the Publisher, only the setting on the publication database is relevant.

パブリケーション データベースでこのオプションを設定すると、パブリケーション データベースでのバックアップが終了するまで、トランザクションがディストリビューション データベースに配信されることはなくなります。Setting this option on the publication database ensures that transactions are not delivered to the distribution database until they are backed up at the publication database. これにより、セカンダリ サーバーでパブリケーション データベースの最後のバックアップを復元したときに、復元されたパブリケーション データベースにないトランザクションが、ディストリビューション データベースに存在する可能性がなくなります。The last publication database backup can then be restored at the secondary server without any possibility of the distribution database having transactions that the restored publication database does not have. このオプションを設定すると、パブリッシャーがセカンダリ サーバーにフェールオーバーした場合でも、パブリッシャー、ディストリビューター、およびサブスクライバーの間で一貫性が保持されます。This option guarantees that if the Publisher fails over to a secondary server, consistency is maintained between the Publisher, Distributor, and Subscribers. パブリッシャーでのバックアップが終了するまでの間、トランザクションがディストリビューション データベースに配信されなくなるため、レプリケーションの待機時間とスループットが影響を受けることになります。アプリケーションがこうした待機時間の遅延を許容できる場合は、パブリケーション データベースでこのオプションを設定することをお勧めします。Latency and throughput are affected because transactions cannot be delivered to the distribution database until they have been backed up at the Publisher; if your application can tolerate this latency, we recommend that you set this option on the publication database. sync with backup オプションが設定されていない場合は、セカンダリ サーバーで復元されたデータベースに含まれていない変更をサブスクライバーが受信する可能性があります。If the sync with backup option is not set, Subscribers might receive changes that are no longer included in the recovered database at the secondary server. 詳細については、「 スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式」を参照してください。For more information, see Strategies for Backing Up and Restoring Snapshot and Transactional Replication.

sync with backup オプションを使用してトランザクション レプリケーションとログ配布を構成するにはTo configure transactional replication and log shipping with the sync with backup option

  1. パブリケーション データベースで sync with backup オプションが設定されていない場合は、 sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'を実行します。If the sync with backup option is not set on the publication database, execute sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. 詳細については、「sp_replicationdboption (Transact-SQL)」を参照してください。For more information, see sp_replicationdboption (Transact-SQL).

  2. パブリケーション データベースに対してログ配布を構成します。Configure log shipping for the publication database. 詳細については、「ログ配布の構成 (SQL Server)」を参照してください。For more information, see Configure Log Shipping (SQL Server).

  3. パブリッシャーに障害が発生した場合は、RESTORE LOG の KEEP_REPLICATION オプションを使用して、データベースの最新のログをセカンダリ サーバーに復元します。If the Publisher fails, restore the last log of the database to the secondary server, using the KEEP_REPLICATION option of RESTORE LOG. これにより、データベースのレプリケーション設定がすべて保持されます。This retains all replication settings for the database. 詳細については、「ログ配布のセカンダリへのフェールオーバー (SQL Server)」および「RESTORE (Transact-SQL)」を参照してください。For more information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).

  4. msdb データベースおよび master データベースをプライマリからセカンダリに復元します。Restore the msdb database and master databases from the primary to the secondary. 詳細については、「システム データベースのバックアップと復元 (SQL Server)」を参照してください。For more information, see Back Up and Restore of System Databases (SQL Server). プライマリがディストリビューターでもある場合は、ディストリビューション データベースをプライマリからセカンダリに復元します。If the primary was also a Distributor, restore the distribution database from the primary to the secondary.

    これらのデータベースのレプリケーション構成およびレプリケーション設定が、プライマリのパブリケーション データベースと一致する必要があります。These databases must be consistent with the publication database at the primary in terms of replication configuration and settings.

  5. セカンダリ サーバーでコンピューター名を変更し、次にプライマリ サーバー名と一致するように SQL ServerSQL Server のインスタンス名を変更します。At the secondary server, rename the computer and then rename the SQL ServerSQL Server instance to match the primary server name. コンピューター名の変更の詳細については、Windows のマニュアルを参照してください。For information about renaming the computer, see the Windows documentation. サーバーの名前変更の詳細については、「 SQL Server のスタンドアロン インスタンスをホストするコンピューターの名前変更 」および「 SQL Server のフェールオーバー クラスター インスタンスの名前変更」をご覧ください。For information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL Server and Rename a SQL Server Failover Cluster Instance.

  6. プライマリからバックアップしたサービス マスター キーをセカンダリ サーバーで復元します。At the secondary server, restore the service master key that was backed up from the primary. 詳細については、「RESTORE SERVICE MASTER KEY (Transact-SQL)」を参照してください。For more information, see RESTORE SERVICE MASTER KEY (Transact-SQL).

sync with backup オプションを使用しないでトランザクション レプリケーションとログ配布を構成するにはTo configure transactional replication and log shipping without the sync with backup option

  1. パブリケーション データベースに対してログ配布を構成します。Configure log shipping for the publication database. 詳細については、「ログ配布の構成 (SQL Server)」を参照してください。For more information, see Configure Log Shipping (SQL Server).

  2. パブリッシャーに障害が発生した場合は、RESTORE LOG の KEEP_REPLICATION オプションを使用して、データベースの最新のログをセカンダリ サーバーに復元します。If the Publisher fails, restore the last log of the database to the secondary server, using the KEEP_REPLICATION option of RESTORE LOG. これにより、データベースのレプリケーション設定がすべて保持されます。This retains all replication settings for the database. 詳細については、「ログ配布のセカンダリへのフェールオーバー (SQL Server)」および「RESTORE (Transact-SQL)」を参照してください。For more information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).

  3. msdb データベースおよび master データベースをプライマリからセカンダリに復元します。Restore the msdb database and master databases from the primary to the secondary. 詳細については、「システム データベースのバックアップと復元 (SQL Server)」を参照してください。For more information, see Back Up and Restore of System Databases (SQL Server). プライマリがディストリビューターでもある場合は、ディストリビューション データベースをプライマリからセカンダリに復元します。If the primary was also a Distributor, restore the distribution database from the primary to the secondary.

    これらのデータベースのレプリケーション構成およびレプリケーション設定が、プライマリのパブリケーション データベースと一致する必要があります。These databases must be consistent with the publication database at the primary in terms of replication configuration and settings.

  4. セカンダリ サーバーでコンピューター名を変更し、次にプライマリ サーバー名と一致するように SQL ServerSQL Server のインスタンス名を変更します。At the secondary server, rename the computer and then rename the SQL ServerSQL Server instance to match the primary server name. コンピューター名の変更の詳細については、Windows のマニュアルを参照してください。For information about renaming the computer, see the Windows documentation. サーバーの名前変更の詳細については、「 SQL Server のスタンドアロン インスタンスをホストするコンピューターの名前変更 」および「 SQL Server のフェールオーバー クラスター インスタンスの名前変更」をご覧ください。For information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL Server and Rename a SQL Server Failover Cluster Instance.

    パブリケーション データベースとディストリビューション データベースが同期していないことを示す、ログ リーダー エージェントのエラー メッセージが表示される場合があります。You might receive an error message from the Log Reader Agent that the publication database and the distribution database are not synchronized.

  5. プライマリからバックアップしたサービス マスター キーをセカンダリ サーバーで復元します。At the secondary server, restore the service master key that was backed up from the primary. 詳細については、「RESTORE SERVICE MASTER KEY (Transact-SQL)」を参照してください。For more information, see RESTORE SERVICE MASTER KEY (Transact-SQL).

  6. sp_replrestart を実行します。Execute sp_replrestart. このストアド プロシージャを使用すると、パブリケーション データベースのログに記録されたレプリケート済みのトランザクションが、ログ リーダー エージェントによってすべて無視されることになります。This stored procedure can be used to force the Log Reader Agent to ignore all the previous replicated transactions in the publication database log. ストアド プロシージャが完了した後で適用されたトランザクションは、ログ リーダー エージェントによって処理されます。Transactions applied after the completion of the stored procedure are processed by the Log Reader Agent. 詳細については、「sp_replrestart (Transact-SQL)」を参照してください。For more information, see sp_replrestart (Transact-SQL).

  7. ストアド プロシージャが正常に終了したら、ログ リーダー エージェントを再起動します。Restart the Log Reader Agent after the stored procedure executes successfully. 詳細については、「レプリケーション エージェントを起動および停止する (SQL Server Management Studio)」を参照してください。For more information, see Start and Stop a Replication Agent (SQL Server Management Studio).

  8. サブスクライバーに既に配信されたトランザクションがパブリッシャーで適用される場合があります。Transactions that have already been distributed to Subscriber might be applied at the Publisher. これらのトランザクションをサブスクライバーで再適用する場合に、ディストリビューション エージェントがエラーで異常終了しないようにするには、" データ一貫性エラー時続行" という名前のエージェント プロファイルを指定します。To ensure that the Distribution Agent does not fail with an error when attempting to reapply these transactions at a Subscriber, specify the agent profile titled Continue On Data Consistency Errors.

マージ レプリケーションのログ配布Log Shipping with Merge Replication

マージ レプリケーションとログ配布を構成するには、以下の手順を実行します。Follow the steps in the procedure below to configure merge replication and log shipping.

マージ レプリケーションとログ配布を構成するにはTo configure merge replication and log shipping

  1. パブリケーション データベースに対してログ配布を構成します。Configure log shipping for the publication database. 詳細については、「 ログ配布の構成 (SQL Server)で導入されました。For more information, see Configure Log Shipping (SQL Server).

  2. パブリッシャーに障害が発生した場合は、セカンダリ サーバーでコンピューター名を変更し、次にプライマリ サーバー名と一致するように SQL ServerSQL Server のインスタンス名を変更します。If the Publisher fails, at the secondary server, rename the computer and then rename the SQL ServerSQL Server instance to match the primary server name. コンピューター名の変更の詳細については、Windows のマニュアルを参照してください。For information about renaming the computer, see the Windows documentation. サーバーの名前変更の詳細については、「 SQL Server のスタンドアロン インスタンスをホストするコンピューターの名前変更 」および「 SQL Server のフェールオーバー クラスター インスタンスの名前変更」をご覧ください。For information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL Server and Rename a SQL Server Failover Cluster Instance.

  3. RESTORE LOG の KEEP_REPLICATION オプションを使用して、データベースの最新のログをセカンダリ サーバーに復元します。Restore the last log of the database to the secondary server, using the KEEP_REPLICATION option of RESTORE LOG. これにより、データベースのレプリケーション設定がすべて保持されます。This retains all replication settings for the database. 詳細については、「ログ配布のセカンダリへのフェールオーバー (SQL Server)」および「RESTORE (Transact-SQL)」を参照してください。For more information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).

  4. msdb データベースおよび master データベースをプライマリからセカンダリに復元します。Restore the msdb database and master databases from the primary to the secondary. 詳細については、「システム データベースのバックアップと復元 (SQL Server)」を参照してください。For more information, see Back Up and Restore of System Databases (SQL Server). プライマリがディストリビューターでもある場合は、ディストリビューション データベースをプライマリからセカンダリに復元します。If the primary was also a Distributor, restore the distribution database from the primary to the secondary.

    これらのデータベースのレプリケーション構成およびレプリケーション設定が、プライマリのパブリケーション データベースと一致する必要があります。These databases must be consistent with the publication database at the primary in terms of replication configuration and settings.

  5. プライマリからバックアップしたサービス マスター キーをセカンダリ サーバーで復元します。At the secondary server, restore the service master key that was backed up from the primary. 詳細については、「RESTORE SERVICE MASTER KEY (Transact-SQL)」を参照してください。For more information, see RESTORE SERVICE MASTER KEY (Transact-SQL).

  6. パブリケーション データベースを 1 つ以上のサブスクリプション データベースと同期します。Synchronize the publication database with one or more subscription databases. これにより、復元されたバックアップに反映されていないパブリケーション データベースの変更をアップロードできます。This allows you to upload those changes made previously in the publication database, but not represented in the restored backup. アップロードできるデータは、パブリケーションのフィルター選択方法によって次のように異なります。The data that can be uploaded depends on the way in which a publication is filtered:

    • パブリケーションがフィルター選択されていない場合は、最新のサブスクライバーと同期することでパブリケーション データベースを最新の状態に更新できます。If the publication is not filtered, you should be able to bring the publication database up-to-date by synchronizing with the most up-to-date Subscriber.

    • パブリケーションがフィルター選択されている場合は、パブリケーションを最新の状態に更新できない場合があります。If the publication is filtered, you might not be able to bring the publication database up-to-date. 各サブスクリプションが 1 つの地域の顧客データのみを受信できるようにパーティション分割されているテーブルがあるとします。北、東、南、西のいずれかです。Consider a table that is partitioned such that each subscription receives customer data only for a single region: North, East, South, and West. データの各パーティションに 1 つ以上のサブスクライバーがある場合、各パーティションのサブスクライバーと同期することにより、パブリケーション データベースを最新の状態に更新できます。If there is at least one Subscriber for each partition of data, synchronizing with a Subscriber for each partition should bring the publication database up-to-date. ただし、たとえば、西パーティションのデータがすべてのサブスクライバーにレプリケートされていない場合は、パブリッシャーでこのデータを最新の状態に更新することはできません。However, if data in the West partition, for example, was not replicated to any Subscribers, this data at the Publisher cannot be brought up-to-date. この場合、パブリッシャーとサブスクライバーのデータが集約するように、すべてのサブスクリプションを再初期化することをお勧めします。In this case, we recommend reinitializing all subscriptions so that the data at the Publisher and Subscribers converges. 詳細については、「 サブスクリプションの再初期化」を参照してください。For more information, see Reinitialize Subscriptions.

    SQL ServerSQL Server よりも前のバージョンの SQL Server 2005 (9.x)SQL Server 2005 (9.x)を実行しているサブスクライバーと同期する場合は、サブスクリプションを匿名にすることはできません。このサブスクリプションはクライアント サブスクリプションまたはサーバー サブスクリプション (以前のリリースではローカル サブスクリプションとグローバル サブスクリプションと呼ばれていました) にする必要があります。If you synchronize with a Subscriber that is running a version of SQL ServerSQL Server prior to SQL Server 2005 (9.x)SQL Server 2005 (9.x), the subscription cannot be anonymous; it must be a client subscription or server subscription (referred to as local subscriptions and global subscriptions in previous releases). 詳細については、「 データの同期」を参照してください。For more information, see Synchronize Data.

参照See Also

SQL Server のレプリケーション SQL Server Replication
ログ配布について (SQL Server) About Log Shipping (SQL Server)
データベース ミラーリングとレプリケーション (SQL Server)Database Mirroring and Replication (SQL Server)