ログ配布を SQL Server 2014 (Transact-SQL) にアップグレードする

SQL Server 2005、SQL Server 2008、SQL Server 2008 R2、または SQL Server 2012 から SQL Server 2014 にアップグレードするときに、ログ配布構成を保持できます。 このトピックでは、ログ配布構成をアップグレードするための代替シナリオとベスト プラクティスについて説明します。

アップグレード前にデータを保護する

ベスト プラクティスとして、ログ配布のアップグレードの前にデータを保護することをお勧めします。

データを保護するには

1. すべてのプライマリ データベースでデータベースの完全バックアップを実行します。

   詳細については、「フル データベース バックアップの作成 (SQL Server)」を参照してください。

2. すべてのプライマリ データベースで DBCC CHECKDB コマンドを実行します。

モニター サーバー インスタンスのアップグレード

監視サーバー インスタンスがある場合は、いつでもアップグレードできます。

モニター サーバーのアップグレード中は、ログ配布構成は引き続き機能しますが、その状態はモニター上のテーブルには記録されません。 監視サーバーのアップグレード中は、構成されているアラートはトリガーされません。 アップグレード後、 sp_refresh_log_shipping_monitor システム ストアド プロシージャを実行して、モニター テーブル内の情報を更新できます。

単一のセカンダリ サーバーを使用したログ配布構成のアップグレード

このセクションで説明するアップグレード プロセスでは、プライマリ サーバーと 1 つのセカンダリ サーバーのみで構成される構成を前提としています。 この構成は、プライマリ サーバー インスタンス A と 1 つのセカンダリ サーバー インスタンス B を示す次の図で表されています。

複数のセカンダリ サーバーのアップグレードについては、このトピックで後述 する「複数のセカンダリ サーバー インスタンスのアップグレード」を参照してください。

セカンダリ サーバー インスタンスのアップグレード

アップグレード プロセスでは、プライマリ サーバー インスタンスをアップグレードする前に、SQL Server 2005 以降のログ配布構成のセカンダリ サーバー インスタンスを SQL Server 2014 にアップグレードする必要があります。 常にセカンダリ サーバー インスタンスを最初にアップグレードします。 プライマリ サーバーがセカンダリ サーバーより前にアップグレードされた場合、新しいバージョンのSQL Serverで作成されたバックアップを古いバージョンのSQL Serverに復元できないため、ログ配布は失敗します。

アップグレードされたセカンダリ サーバーは引き続き SQL Server 2005 以降のプライマリ サーバーからログ バックアップを復元するため、アップグレード プロセス全体でログ配布が続行されます。 セカンダリ サーバー インスタンスをアップグレードするプロセスは、ログ配布構成に複数のセカンダリ サーバーがあるかどうかによって一部異なります。 詳細については、このトピックで後述 する「複数のセカンダリ サーバー インスタンスのアップグレード」を参照してください。

セカンダリ サーバー インスタンスのアップグレード中は、ログ配布のコピー ジョブと復元ジョブは実行されないため、保存されていないトランザクション ログ バックアップが蓄積されます。 累積量は、プライマリ サーバーでのスケジュールされたバックアップの頻度によって異なります。 また、別のモニター サーバーが構成されている場合は、構成された間隔よりも長く復元が実行されていないことを示すアラートが発生する可能性があります。

セカンダリ サーバーがアップグレードされると、ログ配布エージェント ジョブが再開され、プライマリ サーバー インスタンスであるサーバー A からログ バックアップのコピーと復元が続行されます。セカンダリ サーバーがセカンダリ データベースを最新の状態に保つのに必要な時間は、セカンダリ サーバーのアップグレードにかかる時間と、プライマリ サーバーでのバックアップの頻度によって異なります。

プライマリ サーバー インスタンスのアップグレード

アップグレードを計画する際には、データベースが使用できなくなる時間が大きく考慮されます。 最も簡単なアップグレード シナリオでは、プライマリ サーバーのアップグレード中にデータベースが使用できなくなります (シナリオ 1 以下)。

より複雑なアップグレード プロセスでは、元のプライマリ サーバーをアップグレードする前に、SQL Server 2005 以降のプライマリ サーバーを SQL Server 2014 セカンダリ サーバーにフェールオーバーすることで、データベースの可用性を最大化できます (以下のシナリオ 2)。 フェールオーバー シナリオには 2 つのバリエーションがあります。 元のプライマリ サーバーに戻り、元のログ配布構成を保持できます。 または、元のプライマリ サーバーをアップグレードする前に元のログ配布構成を削除し、後で新しいプライマリ サーバーを使用して新しい構成を作成することもできます。 このセクションでは、これらの両方のシナリオについて説明します。

シナリオ 1: フェールオーバーなしでプライマリ サーバー インスタンスをアップグレードする

これは簡単なシナリオですが、フェールオーバーを使用するよりも多くのダウンタイムが発生します。 プライマリ サーバー インスタンスは単にアップグレードされ、このアップグレード中はデータベースを使用できません。

サーバーがアップグレードされると、データベースは自動的にオンラインに戻され、アップグレードされます。 データベースがアップグレードされると、ログ配布ジョブが再開されます。

シナリオ 2: フェールオーバーを使用してプライマリ サーバー インスタンスをアップグレードする

このシナリオでは、可用性を最大化し、ダウンタイムを最小限に抑えます。 セカンダリ サーバー インスタンスへの制御されたフェールオーバーが利用され、元のプライマリ サーバー インスタンスのアップグレード中にデータベースを使用できます。 ダウンタイムは、プライマリ サーバー インスタンスのアップグレードに必要な時間ではなく、フェールオーバーに必要な比較的短い時間に制限されます。

フェールオーバーを伴うプライマリ サーバー インスタンスのアップグレードには、3 つの一般的な手順 (セカンダリ サーバーへの制御されたフェールオーバーの実行、元のプライマリ サーバー インスタンスの SQL Server 2014 へのアップグレード、SQL Server 2014 プライマリ サーバー インスタンスでのログ配布の設定) が含まれます。 これらの手順については、このセクションで説明します。

手順 1: セカンダリ サーバーへの制御されたフェールオーバーを実行する

セカンダリ サーバーへの制御されたフェールオーバー:

1. WITH NORECOVERY を指定して、プライマリ データベースでトランザクション ログの ログ末尾バックアップ を手動で実行します。 このログ バックアップでは、まだバックアップされていないログ レコードがキャプチャされ、データベースがオフラインになります。 データベースがオフラインの間は、ログ配布バックアップ ジョブが失敗することに注意してください。

   次の例では、プライマリ サーバー上の AdventureWorks データベースのログ末尾バックアップを作成します。 バックアップ ファイルの名前は次 Failover_AW_20080315.trn。

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

   手動で作成されたバックアップ ファイルと、ログ配布バックアップ ジョブによって作成されたバックアップ ファイルを区別するには、個別のファイル名前付け規則を使用することをお勧めします。

2. セカンダリ サーバーで次の手順を実行します。

   1. ログ配布バックアップ ジョブによって自動的に作成されたすべてのバックアップが適用されていることを確認します。 どのバックアップ ジョブが適用されているかを確認するには、モニター サーバーまたはプライマリ サーバーとセカンダリ サーバーで sp_help_log_shipping_monitor システム ストアド プロシージャを使用します。 同じファイルを last_backup_file、 last_copied_file、 およびlast_restored_file列に 一覧表示する必要があります。 バックアップ ファイルのいずれかがコピーおよび復元されていない場合は、ログ配布構成のエージェントのコピーおよび復元ジョブを手動で呼び出します。

      ジョブの開始については、「ジョブの開始」 を参照してください。

   2. 手順 1 で作成した最終的なログ バックアップ ファイルをファイル共有から、セカンダリ サーバーのログ配布で使用されるローカルの場所にコピーします。

   3. WITH RECOVERY を指定して最終的なログ バックアップを復元して、データベースをオンラインにします。 オンライン化の一環として、データベースは SQL Server 2014 にアップグレードされます。

      次の例では、セカンダリ データベース上の AdventureWorks データベースのログ末尾バックアップを復元します。 この例では、WITH RECOVERY オプションを使用します。これにより、データベースがオンラインになります。

      RESTORE LOG AdventureWorks 
        FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
         WITH RECOVERY;
      GO
      

      Note

      複数のセカンダリ サーバーを含む構成の場合は、追加の考慮事項があります。 詳細については、このトピックで後述 する「複数のセカンダリ サーバー インスタンスのアップグレード」を参照してください。

   4. 元のプライマリ サーバー (サーバー A) からオンライン セカンダリ サーバー (サーバー B) にクライアントをリダイレクトして、データベースをフェールオーバーします。

   5. データベースがオンラインの間、セカンダリ データベースのトランザクション ログがいっぱいにならないことに注意してください。 トランザクション ログがいっぱいにならないように、バックアップが必要な場合があります。 その場合は、バックアップを他のサーバー インスタンスで復元できるように、共有の場所 ( バックアップ共有) にバックアップすることをお勧めします。

手順 2: 元のプライマリ サーバー インスタンスを SQL Server 2014 にアップグレードする

元のプライマリ サーバー インスタンスを SQL Server 2014 にアップグレードした後も、データベースはオフラインになり、その形式になります。

手順 3: SQL Server 2014 でログ配布を設定する

アップグレード プロセスの残りの部分は、次のようにログ配布がまだ構成されているかどうかによって異なります。

• SQL Server 2005or より高いログ配布構成を保持している場合は、元のプライマリ サーバー インスタンスに切り替えます。 詳細については、このセクションで後述 する「元のプライマリ サーバー インスタンスに切り替えるには」を参照してください。

• フェールオーバーする前にログ配布構成を削除した場合は、元のセカンダリ サーバー インスタンスが新しいプライマリ サーバー インスタンスである新しいログ配布構成を作成します。 詳細については、このセクションで後述 する「古いセカンダリ サーバー インスタンスを新しいプライマリ サーバー インスタンスとして保持するには」を参照してください。

元のプライマリ サーバー インスタンスに戻すには

1. 中間プライマリ サーバー (サーバー B) で、WITH NORECOVERY を使用してログの末尾をバックアップし、ログ末尾のバックアップを作成し、データベースをオフラインにします。 ログ末尾のバックアップには、 Switchback_AW_20080315.trnという名前が付けられます。例えば：

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

2. 手順 1 で作成した末尾バックアップ以外のトランザクション ログ バックアップが中間プライマリ データベースで作成された場合は、WITH NORECOVERY を使用してそれらのログ バックアップを元のプライマリ サーバー (サーバー A) 上のオフライン データベースに復元します。 データベースは、最初のログ バックアップが復元されるときに、SQL Server 2014 形式にアップグレードされます。

3. WITH RECOVERY を使用して元のプライマリ データベース (サーバー A) でログ末尾のバックアップ ( Switchback_AW_20080315.trn) を復元し、データベースをオンラインにします。

4. クライアントを元のプライマリ サーバーからオンライン セカンダリ サーバーにリダイレクトして、元のプライマリ データベース (サーバー A) にフェールオーバーします。

データベースがオンラインになると、元のログ配布構成が再開されます。

古いセカンダリ サーバー インスタンスを新しいプライマリ サーバー インスタンスとして保持するには

次のように、古いセカンダリ サーバー インスタンス B をプライマリ サーバーとして使用し、古いプライマリ サーバー インスタンス A を新しいセカンダリ サーバーとして使用して、新しいログ配布構成を確立します。

1. 新しいセカンダリ サーバー (サーバー A) でデータベースの完全なバックアップと復元を実行しないようにするには、新しいプライマリ データベースから新しいセカンダリ データベースにログ バックアップを適用します。 この構成例では、サーバー B で作成されたログ バックアップをサーバー A 上のデータベースに復元する必要があります。

2. 新しいプライマリ データベース (サーバー B) からログをバックアップします。

3. WITH NORECOVERY を使用して、新しいセカンダリ サーバー インスタンス (サーバー A) にログ バックアップを復元します。 最初の復元操作では、データベースが SQL Server 2014 に更新されます。

4. 以前のセカンダリ サーバー (サーバー B) をプライマリ サーバー インスタンスとして使用してログ配布を構成します。

   Important

   SQL Server Management Studioを使用する場合は、セカンダリ データベースが既に初期化されていることを指定します。

   詳細については、「ログ配布の構成 (SQL Server)」を参照してください。

5. 元のプライマリ サーバー (サーバー A) からオンライン セカンダリ サーバー (サーバー B) にクライアントをリダイレクトして、データベースをフェールオーバーします。

   Important

   新しいプライマリ データベースにフェールオーバーするときは、そのメタデータが元のプライマリ データベースのメタデータと一致していることを確認する必要があります。 詳細については、「データベースを別のサーバー インスタンスで使用できるようにするときのメタデータの管理 (SQL Server)」を参照してください。

複数のセカンダリ サーバー インスタンスのアップグレード

この構成は、プライマリ サーバー インスタンス A と 2 つのセカンダリ サーバー インスタンス B と C を示す次の図に示されています。

このセクションでは、フェールオーバーを使用してアップグレードし、元のプライマリ サーバーに切り替える方法について説明します。 フェールオーバーを使用してプライマリ インスタンスをアップグレードする場合、複数のセカンダリ サーバー インスタンスがある場合、プロセスはより複雑になります。 次の手順では、すべてのセカンダリ サーバーがアップグレードされると、アップグレードされたセカンダリ データベースのいずれかにプライマリ サーバーがフェールオーバーされます。 元のプライマリ サーバーがアップグレードされ、ログ配布がフェールオーバーされます。

フェールオーバーを使用してアップグレードし、元のプライマリ サーバーに切り替える

1. すべてのセカンダリ サーバー インスタンス (サーバー B とサーバー C) をアップグレードします。

2. WITH NORECOVERY を使用してトランザクション ログをバックアップすることにより、プライマリ データベース (サーバー A) のトランザクション ログの末尾を取得し、データベースをオフラインにします。

3. フェールオーバーを計画しているセカンダリ サーバー (サーバー B) で、WITH RECOVERY を使用してログ バックアップを復元して、セカンダリ データベースをオンラインにします。

4. 他のすべてのセカンダリ サーバー (サーバー C) で、WITH NORECOVERY を使用してログ バックアップを復元することで、セカンダリ データベースをオフラインのままにします。

   Note

   ログ配布のコピー ジョブと復元ジョブはセカンダリ サーバーで実行されますが、新しいログ バックアップ ファイルはバックアップ共有に配置されないため、ジョブは何も実行しません。

5. 元のプライマリ サーバー (サーバー A) からオンライン セカンダリ サーバー (サーバー B) にクライアントをリダイレクトして、データベースをフェールオーバーします。 オンライン データベースは中間プライマリ サーバーになり、元のプライマリ サーバーがオフライン (サーバー A) の間はデータベースを使用できます。

6. 元のプライマリ サーバー (サーバー A) をアップグレードします。

7. 中間プライマリ データベースをフェールオーバーしたデータベース (サーバー B) で、WITH NORECOVERY を使用してトランザクション ログを手動でバックアップします。 これにより、データベースがオフラインになります。

8. WITH NORECOVERY を使用して、中間プライマリ データベース (サーバー B) で作成したすべてのトランザクション ログ バックアップを他のすべてのセカンダリ データベース (サーバー C) に復元します。 これにより、アップグレード後も元のプライマリ データベースからログ配布を続行できます。各セカンダリ データベースでデータベース全体を復元する必要はありません。

9. WITH RECOVERY を使用して、中間プライマリ サーバー (サーバー B) から元のプライマリ データベース (サーバー A 上) にトランザクション ログを復元します。

ログ配布の再デプロイ

上記のいずれかの手順を使用してログ配布構成を移行しない場合は、プライマリ データベースの完全バックアップと復元を使用してセカンダリ データベースを再初期化することで、ログ配布を最初から再デプロイできます。 データベースが小さい場合や、アップグレード手順中に高可用性が重要でない場合は、このオプションが望ましい場合があります。

ログ配布を有効にする方法については、「ログ配布の構成 (SQL Server)」を参照してください。

こちらもご覧ください

トランザクション ログ バックアップ (SQL Server)トランザクション ログ バックアップの適用 (SQL Server)ログ配布テーブルとストアド プロシージャ