レプリケーションとログ配布
ログ配布では単一のデータベースの 2 つのコピーを使用します。通常、これらのコピーは異なるコンピュータに配置されます。クライアントが任意の時点において使用できるデータベースのコピーは 1 つだけです。このコピーはプライマリ データベースと呼ばれます。クライアントがプライマリ データベースに対して加えた更新は、ログ配布によってセカンダリ データベースと呼ばれるもう一方のコピー データベースに適用されます。プライマリ データベースに対して行われた挿入、更新、および削除はすべてトランザクション ログに記録され、ログ配布によってこのトランザクション ログがセカンダリ データベースに適用されます。
ログ配布はレプリケーションと組み合わせて使用できます。ログ配布とレプリケーションを併用した場合の動作を以下に示します。
ログ配布でフェールオーバーが発生すると、レプリケーションが停止します。フェールオーバーが発生した場合、レプリケーション エージェントはセカンダリに接続しません。その結果、トランザクションがサブスクライバにレプリケートされなくなります。プライマリへのフェールバックが行われると、レプリケーションが再開されます。ログ配布によってセカンダリからプライマリにコピーされたすべてのトランザクションがサブスクライバにレプリケートされます。
プライマリが完全に失われた場合、セカンダリの名前を変更してレプリケーションを継続できます。このトピックの残りの部分では、こうしたケースを処理する場合の要件と手順について説明します。ログ配布を使用する最も一般的なデータベースであるパブリケーション データベースを例として使用します。ただし、サブスクリプション データベースおよびディストリビューション データベースについても同様の手順を適用できます。
レプリケーションを再構成することなく、レプリケーションに関連するデータベースを復元する場合の詳細については、「レプリケートされたデータベースのバックアップと復元」を参照してください。
.gif "注意") 注意 |
|---|
パブリケーション データベースの可用性を提供することが目的の場合は、ログ配布ではなく、データベース ミラーリングを使用することをお勧めします。詳細については、「レプリケーションおよびデータベース ミラーリング」を参照してください。 |
プライマリが失われた場合にセカンダリからレプリケートを行うための要件と手順
以下の要件および考慮事項に注意してください。
プライマリに複数のパブリケーション データベースが格納されている場合、すべてのパブリケーション データベースのログが同一のセカンダリに配布されます。
セカンダリ サーバー インスタンスのインストール パスは、プライマリ サーバー インスタンスのインストール パスと同一にする必要があります。セカンダリ サーバー上のユーザー データベースの場所は、プライマリ サーバー上の場所と同一にする必要があります。
プライマリでサービス マスタ キーをバックアップします。このキーはセカンダリで復元されます。詳細については、「BACKUP SERVICE MASTER KEY (Transact-SQL)」を参照してください。
ログ配布では、データ損失の回避は保障されません。プライマリ データベースで障害が発生した場合、バックアップされていないデータが失われたり、障害時にバックアップ用のデータが失われる可能性があります。
トランザクション レプリケーションのログ配布
トランザクション レプリケーションの場合、ログ配布の動作は sync with backup オプションの設定によって異なります。このオプションは、パブリケーション データベースおよびディストリビューション データベースで設定できます。パブリッシャのログ配布では、パブリケーション データベースでの設定のみが関係します。
パブリケーション データベースでこのオプションを設定すると、パブリケーション データベースでのバックアップが終了するまで、トランザクションがディストリビューション データベースに配信されることはなくなります。これにより、セカンダリ サーバーでパブリケーション データベースの最後のバックアップを復元したときに、復元されたパブリケーション データベースにないトランザクションが、ディストリビューション データベースに存在する可能性がなくなります。このオプションを設定すると、パブリッシャがセカンダリ サーバーにフェールオーバーした場合でも、パブリッシャ、ディストリビュータ、およびサブスクライバの間で一貫性が保持されます。パブリッシャでのバックアップが終了するまでの間、トランザクションがディストリビューション データベースに配信されなくなるため、レプリケーションの待機時間とスループットが影響を受けることになります。アプリケーションがこうした待機時間の遅延を許容できる場合は、パブリケーション データベースでこのオプションを設定することをお勧めします。sync with backup オプションが設定されていない場合は、セカンダリ サーバーで復元されたデータベースに含まれていない変更をサブスクライバが受信する可能性があります。詳細については、「スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式」を参照してください。
sync with backup オプションを使用してトランザクション レプリケーションとログ配布を構成するには
パブリケーション データベースで sync with backup オプションが設定されていない場合は、sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true' を実行します。詳細については、「sp_replicationdboption (Transact-SQL)」を参照してください。
パブリケーション データベースに対してログ配布を構成します。詳細については、「ログ配布の配置」を参照してください。
パブリッシャに障害が発生した場合は、RESTORE LOG の KEEP_REPLICATION オプションを使用して、データベースの最新のログをセカンダリ サーバーに復元します。これにより、データベースのレプリケーション設定がすべて保持されます。詳細については、「ログ配布のセカンダリへのフェールオーバー」および「RESTORE (Transact-SQL)」を参照してください。
msdb データベースおよび master データベースをプライマリからセカンダリに復元します。詳細については、「model データベースおよび msdb データベースの復元に関する注意点」および「master データベースの復元に関する注意点」を参照してください。プライマリがディストリビュータでもある場合は、ディストリビューション データベースをプライマリからセカンダリに復元します。
これらのデータベースのレプリケーション構成およびレプリケーション設定が、プライマリのパブリケーション データベースと一致する必要があります。
セカンダリ サーバーでコンピュータ名を変更し、次にプライマリ サーバー名と一致するように MicrosoftSQL Server のインスタンス名を変更します。コンピュータ名の変更の詳細については、Windows のマニュアルを参照してください。サーバー名の変更の詳細については、「SQL Server スタンドアロン インスタンスをホストするコンピュータの名前を変更する方法」および「SQL Server のフェールオーバー クラスタ インスタンスの名前を変更する方法」を参照してください。
プライマリからバックアップしたサービス マスタ キーをセカンダリ サーバーで復元します。詳細については、「RESTORE SERVICE MASTER KEY (Transact-SQL)」を参照してください。
sync with backup オプションを使用しないでトランザクション レプリケーションとログ配布を構成するには
パブリケーション データベースに対してログ配布を構成します。詳細については、「ログ配布の配置」を参照してください。
パブリッシャに障害が発生した場合は、RESTORE LOG の KEEP_REPLICATION オプションを使用して、データベースの最新のログをセカンダリ サーバーに復元します。これにより、データベースのレプリケーション設定がすべて保持されます。詳細については、「ログ配布のセカンダリへのフェールオーバー」および「RESTORE (Transact-SQL)」を参照してください。
msdb データベースおよび master データベースをプライマリからセカンダリに復元します。詳細については、「model データベースおよび msdb データベースの復元に関する注意点」および「master データベースの復元に関する注意点」を参照してください。プライマリがディストリビュータでもある場合は、ディストリビューション データベースをプライマリからセカンダリに復元します。
これらのデータベースのレプリケーション構成およびレプリケーション設定が、プライマリのパブリケーション データベースと一致する必要があります。
セカンダリ サーバーでコンピュータ名を変更し、次にプライマリ サーバー名と一致するように SQL Server のインスタンス名を変更します。コンピュータ名の変更の詳細については、Windows のマニュアルを参照してください。サーバー名の変更の詳細については、「SQL Server スタンドアロン インスタンスをホストするコンピュータの名前を変更する方法」および「SQL Server のフェールオーバー クラスタ インスタンスの名前を変更する方法」を参照してください。
パブリケーション データベースとディストリビューション データベースが同期していないことを示す、ログ リーダー エージェントのエラー メッセージが表示される場合があります。
プライマリからバックアップしたサービス マスタ キーをセカンダリ サーバーで復元します。詳細については、「RESTORE SERVICE MASTER KEY (Transact-SQL)」を参照してください。
sp_replrestart を実行します。このストアド プロシージャを使用すると、パブリケーション データベースのログに記録されたレプリケート済みのトランザクションが、ログ リーダー エージェントによってすべて無視されることになります。ストアド プロシージャが完了した後で適用されたトランザクションは、ログ リーダー エージェントによって処理されます。詳細については、「sp_replrestart (Transact-SQL)」を参照してください。
ストアド プロシージャが正常に終了したら、ログ リーダー エージェントを再起動します。詳細については、「レプリケーション エージェントの起動および停止方法 (SQL Server Management Studio)」を参照してください。
サブスクライバに既に配信されたトランザクションがパブリッシャで適用される場合があります。これらのトランザクションをサブスクライバで再適用する場合に、ディストリビューション エージェントがエラーで異常終了しないようにするには、"データ一貫性エラー時続行" という名前のエージェント プロファイルを指定します。詳細については、「トランザクション レプリケーションでのエラーのスキップ」を参照してください。
マージ レプリケーションのログ配布
マージ レプリケーションとログ配布を構成するには、以下の手順を実行します。
マージ レプリケーションとログ配布を構成するには
パブリケーション データベースに対してログ配布を構成します。詳細については、「ログ配布の配置」を参照してください。
パブリッシャに障害が発生した場合は、RESTORE LOG の KEEP_REPLICATION オプションを使用して、データベースの最新のログをセカンダリ サーバーに復元します。これにより、データベースのレプリケーション設定がすべて保持されます。詳細については、「ログ配布のセカンダリへのフェールオーバー」および「RESTORE (Transact-SQL)」を参照してください。
msdb データベースおよび master データベースをプライマリからセカンダリに復元します。詳細については、「model データベースおよび msdb データベースの復元に関する注意点」および「master データベースの復元に関する注意点」を参照してください。プライマリがディストリビュータでもある場合は、ディストリビューション データベースをプライマリからセカンダリに復元します。
これらのデータベースのレプリケーション構成およびレプリケーション設定が、プライマリのパブリケーション データベースと一致する必要があります。
セカンダリ サーバーでコンピュータ名を変更し、次にプライマリ サーバー名と一致するように SQL Server のインスタンス名を変更します。コンピュータ名の変更の詳細については、Windows のマニュアルを参照してください。サーバー名の変更の詳細については、「SQL Server スタンドアロン インスタンスをホストするコンピュータの名前を変更する方法」および「SQL Server のフェールオーバー クラスタ インスタンスの名前を変更する方法」を参照してください。
プライマリからバックアップしたサービス マスタ キーをセカンダリ サーバーで復元します。詳細については、「RESTORE SERVICE MASTER KEY (Transact-SQL)」を参照してください。
パブリケーション データベースを 1 つ以上のサブスクリプション データベースと同期します。これにより、復元されたバックアップに反映されていないパブリケーション データベースの変更をアップロードできます。アップロードできるデータは、パブリケーションのフィルタ選択方法によって次のように異なります。
パブリケーションがフィルタ選択されていない場合は、最新のサブスクライバと同期することでパブリケーション データベースを最新の状態に更新できます。
パブリケーションがフィルタ選択されている場合は、パブリケーションを最新の状態に更新できない場合があります。たとえば、各サブスクリプションが 1 つの地域 (北、東、南、西のいずれか) の顧客データのみを受信できるようにパーティション分割されているテーブルがあるとします。データの各パーティションに少なくとも 1 つのサブスクライバがある場合、各パーティションのサブスクライバと同期することにより、パブリケーション データベースを最新の状態に更新できます。ただし、たとえば、西パーティションのデータがどのサブスクライバにもレプリケートされていない場合は、パブリッシャでこのデータを最新の状態に更新することはできません。この場合、パブリッシャとサブスクライバのデータが集約するように、すべてのサブスクリプションを再初期化することをお勧めします。詳細については、「サブスクリプションの再初期化」を参照してください。
SQL Server 2005 よりも前のバージョンの SQL Server を実行しているサブスクライバと同期する場合は、サブスクリプションを匿名にすることはできません。このサブスクリプションはクライアント サブスクリプションまたはサーバー サブスクリプション (以前のリリースではローカル サブスクリプションとグローバル サブスクリプションと呼ばれていました) にする必要があります。詳細については、「データの同期」を参照してください。