セールス: 1-800-867-1380

ログ配布を使用した Azure インフラストラクチャ サービス上の SQL Server の geo DR

地理的障害復旧 (geo DR) とは、地理的領域全体に影響を及ぼす障害 (自然災害など) から復旧する能力です。Azure™ インフラストラクチャ サービス上でホストされるプライマリ サイトの geo DR を実装するには、異なる地理的領域の 1 つまたは複数のセカンダリ サイトにデータの冗長コピーを保持し、データに加えられた変更をプライマリ サイトからセカンダリ サイトに反映するためのメカニズムを確立する必要があります。

このドキュメントでは、最初に、Azure インフラストラクチャ サービス上の Microsoft® SQL Server® ソフトウェアで利用可能な geo DR オプションの制限について検討します。これらの考慮事項は、基底のテクノロジとしてログ配布を使用した SQL Server 用のカスタム geo DR ソリューションを作成する動機となります。次に、ソリューション アプローチと、このアプローチのソリューション コンポーネントについて説明します。続いて、フェールオーバー中のソリューションで可能な目標復旧時間 (RTO) と目標復旧時点 (RPO) のトレードオフについて説明します。また、このドキュメントでは、(プライマリからセカンダリへの) ロール切り替えと (新しいプライマリから古いプライマリへの) 逆方向のロール切り替えの手順についても説明します。

このソリューションには、次の利点があります。

  • SQL Server のすべてのサポートされるバージョンで使用できます。

  • プライマリ サイトと障害復旧サイトのサーバー間にドメイン関係やファイル共有を設定する必要はありません。

  • 圧縮、HTTP ベースおよび HTTP Secure (HTTPS) ベースの転送、復元オプション (たとえば、standby、norecovery) などのさまざまなオプションがサポートされます。

  • 内部設置のみのシナリオ、Azure インフラストラクチャ サービスのみのシナリオ、または Azure サブスクリプションと Azure BLOB ストレージの両方の利点があるハイブリッド シナリオの SQL Server geo DR 用に使用できます。

Azure インフラストラクチャ サービス上の SQL Server の geo DR 向けのオプションの中では、証明書を使用したデータベース ミラーリングが現実的な選択肢です。ただし、データ センター間のデータベース ミラーリングによる障害復旧を選択した場合、データ センター内でローカルな高可用性を実現することに問題が生じます。これは、データベース ミラーリングでは 1 つのプライマリ データベースに対して 1 つのセカンダリ データベースだけが許可されるためです (さらに、データベース ミラーリングは推奨されていません)。Azure では、現在、データ センター間での仮想ネットワークがサポートされていないため、現時点で AlwaysOn 可用性グループを geo DR オプションとして使用することはできません。SQL Server に装備されている組み込みのログ配布機能はファイル共有に依存します。これも、同じ理由から、Azure データ センター間で運用することはできません。これらの課題により、Azure インフラストラクチャ サービス上の SQL Server の geo DR 向けに、非組み込み型の、構築、運用、必要に応じたカスタマイズが容易なソリューションを求めることになります。

ログ配布の個々の操作には、ログのバックアップ、ファイルのコピー、およびログの復元が含まれます。これらの基本的な操作は、ファイル共有に依存しません。SQL Server エージェント ジョブと共に Transact-SQL スクリプトおよびストアド プロシージャを作成して個々の操作を組み合わせ、これらの基本的な操作を使用する geo DR のための実用的なソリューションを作成できます。このアプローチは、カスタマイズされたログ配布と呼ばれます。

カスタマイズされたログ配布には、プライマリ SQL Server インスタンス上でログ バックアップを実行し、シーケンス番号が付けられたログ バックアップを Azure BLOB ストレージのコンテナーに格納する手順が含まれます。障害復旧サイト上では、Azure BLOB ストレージからログ バックアップを順番に読み取り、ログ バックアップを障害復旧 SQL Server インスタンス上に復元します。Microsoft SQL Server 2012 でのこのアプローチをサポートする例として、URL をターゲットおよびソースとするバックアップおよび復元機能があります。この機能では、SQL Server は、完全バックアップまたはトランザクション ログ バックアップを Azure BLOB ストレージに直接書き込み、バックアップを BLOB ストレージから直接復元します。機能の詳細については、「Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元」を参照してください。

代替のオプションとして、ログ ファイルをローカル ディスクにバックアップし、一般的な AzCopy プログラムを使用してバックアップ ファイルを Azure BLOB ストレージに移動する方法があります。AzCopy プログラムには、ジャーナル ファイルを使用して中断されたコピー操作の状態のレコードを保持し、失敗したコピー操作を再開できる便利な機能があります。再開操作では、コピーされていないファイルの部分からもコピーを再開することもできます。AzCopy プログラムの詳細については、「AzCopy – Uploading and Downloading files for Azure Blobs (AzCopy - Azure BLOB のファイルのアップロードとダウンロード)」を参照してください。

このソリューションのアプローチでは、カスタム ストアド プロシージャを使用して、ログ配布操作 (バックアップ用の Azure 資格情報の提供、データベースまたはログ バックアップ用の Transact-SQL の実行、ファイルのシーケンス番号付け、シーケンス番号順のファイルの復元など) を自動化します。これらのストアド プロシージャは、いくつかの入力パラメーターを受け取り、実行履歴とエラー情報をテーブルに記録します。ストアド プロシージャは、スケジュールされた SQL Server エージェント ジョブを介して呼び出されます。ストアド プロシージャ、ジョブ、およびテーブルをインストールするには、Microsoft .NET ベースのプログラムを使用します。また、Transact-SQL スクリプトを使用してソリューションのコンポーネントを手動でインストールすることもできます。この目的には、.NET コードと Transact SQL スクリプトのサンプルを使用できます。このサンプルには、詳しい説明およびカスタマイズのためのドキュメント『Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』も含まれています。

以降のセクションでは、BLOB ストレージの場所に関するオプションについて説明します。

図 1 に示すように、ログ ファイルの BLOB ストレージは、プライマリ データ センターと同じ場所に割り当てることができます。

この場合、バックアップ ファイルの移動先が同じデータ センター内であるため、プライマリ データ センター上でのログ バックアップ データの BLOB ストアへの移動が高速になります。同じデータ センター内の BLOB ストアへのバックアップ ファイルの移動では、転送料金は発生しません。

障害復旧用のデータ センター内では、BLOB ストアからのログ バックアップ データの移動は、ローカル ディスクからの移動よりも低速になります。これは、データ センター間でデータが移動されるためです。さらに、データ センター間でログ ファイルが転送されるため、データ転送料金が発生します。最終的な考慮事項としては、プライマリ サイトのデータ センターが完全に停止した場合、そこに保存されていて障害復旧サイトへのコピーが完了していないログ バックアップが失われるという点です。

図 1

図 1. プライマリ サイトと同じ場所に配置された BLOB ストレージ

図 2 に示すように、ログ ファイルの BLOB ストレージは、障害復旧用のデータ センターと同じ場所に割り当てることができます。

この場合、BLOB ストアへのログ バックアップ データの移動は、データ センター間でデータが移動されるため、前のオプションよりも低速になります。さらに、データ センター間でデータが転送されるため、データ転送料金が発生します。

障害復旧用のデータ センター内では、ログ バックアップ データの移動は、前のオプションよりも高速になります。これは、データ センター間で通信が発生しないためです。最終的な考慮事項としては、障害復旧サイトのデータ センターが完全に停止した場合、プライマリ サイトのログ バックアップを指定された BLOB ストレージに正常に格納できなくなるという点です。

図 2

図 2. セカンダリ サイトと同じ場所に配置された BLOB ストレージ

カスタマイズされたログ配布アプローチは、主に TSQL SQL スクリプトとサンプル .NET インストーラー プログラムを関連ファイルと共に使用して実装されます。Azure Datacenter Log Shipper (ADLS) と呼ばれるこのソリューションは、次のコンポーネントから構成されています。

  • ADLS インストーラーおよび ADLS インストーラー構成ファイル

  • インストール、ログ バックアップ/復元ストアド プロシージャ、および操作/エラー追跡テーブルを含む ADLS データベース

  • ADLS (SQL Server エージェント) ジョブ

  • オプションで、ログのディスクへのバックアップや BLOB ストレージへの移動をサポートするための AzCopy.exe プログラムが含まれます。

  • Azure のストレージ アカウントの BLOB ストレージ コンテナー

ADLS コンポーネントは、ADLS インストーラーを使用してインストールします。ADLS インストーラーの実行は、構成ファイルのパラメーターに依存します。ADLS インストーラーを SQL Server が実行されているプライマリ (ソース) サーバーまたは障害復旧 (ターゲット) サーバーで実行すると、次の操作が実行されます。

  • ログ配布に必要なソースまたはターゲット コンポーネント (ストアド プロシージャ、テーブル、ジョブ、BLOB コンテナー、および資格情報) を作成する

  • ソース ADLS インストーラー構成ファイルから対応する入力を読み取って実行オプションを設定する

  • ADLS インストーラー構成ファイルの構成に従って、ログ配布ジョブの実行スケジュールを作成する

  • Azure に BLOB ストレージ コンテナーを作成する

プライマリ SQL Server では、ログ配布アクティビティは、インストーラーによって作成された SQL Server エージェント ジョブが指定されたスケジュールに従って呼び出されたときに開始されます。最初のジョブ ステップで、スケジュールされた時間に sp_BackupLog ストアド プロシージャが呼び出されます。sp_BackupLog プロシージャは、ソース データベースの完全バックアップ (1 回目) またはトランザクション ログ バックアップ (2 回目以降) を実行し、バックアップ ファイルの名前とシーケンス番号を適切に設定します。さらに、sp_BackupLog プロシージャは、操作実行履歴を LogBackupInfo テーブルに格納します。エラーが発生した場合、sp_BackupLog はその情報を OperationErrorInfo テーブルに格納します。

sp_BackupLog プロシージャがバックアップ ファイルを書き込む場所は、インストーラー構成によって決定されます。既定のインストール オプションを使用した場合、sp_BackupLog は、バックアップを直接 BLOB ストレージに書き込みます (Transact-SQL BACKUP TO URL)。インストール オプションを使用して、sp_BackupLog がディスク上のローカル フォルダーにバックアップを配置するように設定することもできます。後続のジョブ ステップでは、AzCopy を CmdExec タスクとして呼び出して、バックアップ ファイルを BLOB ストレージに移動します。

障害復旧 SQL Server では、ログ配布アクティビティは、インストーラーによって作成された SQL Server エージェント ジョブがスケジュールされた時刻に実行されたときに開始されます。既定のインストール オプションを使用した場合、sp_RestoreLog は、復旧するファイルを直接 Azure BLOB ストレージ コンテナーから読み取ります (Transact-SQL RESTORE FROM URL)。インストール オプションを使用して、SQL Server エージェント ジョブが sp_RestoreLog の呼び出しの前のステップとして AzCopy を起動して、BLOB ストレージからローカル ディスクにバックアップ ファイルをコピーするように設定することもできます。

sp_RestoreLog は、読み取ったログ ファイルを順に復元し、操作実行履歴を LogRestoreInfo テーブルに格納します。エラーが発生した場合、sp_RestoreLog はその情報を Operation Error Info テーブルに格納します。

図 3 に、ソリューションのコンポーネントとデータ フローを示します。

図 3

図 3. ソリューションのコンポーネントとデータ フロー

ADLS インストーラー構成 (ADLSInstaller.exe.config) ファイルは、ADLS インストーラー (ADLSInstaller.exe) ファイルと同じディレクトリにある、標準 .NET App.config XML 形式のファイルです。

ADLSInstaller.exe.config ストアの名前/値ペアには、パラメーターの名前と対応する値が格納されます。これらのパラメーターは、次の項目を指定します。

  • ADLS インストーラーでソース コンポーネントとターゲット コンポーネントのどちらをインストールするか

  • ログ配布のターゲット (SQL Server インスタンスおよびデータベース)

  • 動作モード (URL またはローカル ディスクへのバックアップ、URL またはローカル ディスクからの復元)

  • Azure パラメーター (ストレージ アカウント、ストレージ アクセス キー、BLOB コンテナー)

  • 復元オプション (復旧モード、スタンバイ ファイルなど)

  • 転送および圧縮オプション

  • ジョブ スケジューリング オプション (頻度、開始日時など)

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、これらのパラメーターの一覧と説明が示されています。

ADLSInstaller.exe を実行する前に、ADLSInstaller.exe.config にインストールのためのパラメーターを設定する必要があります。

ADLS インストーラー (ADLSInstaller.exe) は、ADLS インストーラー構成ファイルを読み取り、ソース コンポーネントおよびターゲット コンポーネントのインストールと構成を行います。ADLS インストーラーは、次のアクションを実行します。

  • ADLS インストーラー構成ファイルからパラメーターを読み取る

  • 指定された名前の Azure BLOB コンテナーを作成する (コンテナーが存在しない場合)

  • SQL Server サービスを起動する (サービスが起動されていない場合)

  • SQL Server エージェント サービスを起動する (サービスが起動されていない場合)

  • ADLSLogShipper データベースを作成する

  • ADLSLogShipper データベース内で、ソースまたはターゲットに必要なテーブル (既存のテーブルがある場合はそれを使用する) およびストアド プロシージャを作成する (既存のストアド プロシージャがある場合はそれを削除する)

  • インストール プロシージャを実行してログ配布ジョブを作成する

ADLS インストーラーを実行するには、引数を指定せずに ADLSInstaller.exe を起動します。

ADLS インストーラーは、ソリューション コンポーネントのセットアップを容易にすることを目的としています。ただし、ADLS インストーラーの使用は必須ではありません。手動セットアップを行うには、SQL Server が実行されているそれぞれのソース コンピューターおよびターゲット コンピューターで次の手順を実行します。

  1. Azure BLOB コンテナーをストレージ アカウントに作成します。

  2. ソース コンピューターとターゲット コンピューターの両方で SQL Server と SQL Server エージェントを起動します。

  3. ソース コンピューターとターゲット コンピューターのそれぞれに、ADLS ストアド プロシージャおよびテーブルを格納するためのデータベースを作成します。

  4. ソース コンピューターとターゲット コンピューターの両方で、ストアド プロシージャおよびテーブルを ADLSLogShipper データベースに作成します (.NET コードと Transact SQL スクリプトを参照してください)。

  5. ソース コンピューター上で適切なパラメーターを使用して sp_ADLS_SourceInstall を実行して、SQL Server エージェント ジョブを作成します (手順については、『Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』を参照してください)。

  6. ターゲット コンピューター上で適切なパラメーターを使用して sp_ADLS_DestnInstall を実行して、SQL Server エージェント ジョブを作成します (手順については、『Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』を参照してください)。

ADLSLogShipper データベースは、ADLS インストーラーによって作成されるテーブルおよびストアド プロシージャのコンテナーとして働きます。このデータベースが存在しない場合は、ADLS インストーラーによって作成されます。

sp_ADLS_SourceInstall ストアド プロシージャは、プライマリ SQL Server (ソース) でのログ配布のために必要な Azure 資格情報およびジョブを作成することを目的としています。sp_ADLS_SourceInstall は、次のアクションを実行します。

  • ADLS インストーラーによって提供された Azure ストレージ アカウント名およびストレージ アクセス キーを使用して、一意の Azure 資格情報を作成します。

  • LogLocationType=0 の場合、データベースまたはトランザクション ログを Azure BLOB ストレージにバックアップするための、指定されたパラメーターを使用して sp_ADLS_BackupLog を起動する単一ステップのジョブを作成します。LogLocationType=1 の場合、sp_ADLS_BackupLog を実行した後に AzCopy を起動する、2 つのステップから構成されるジョブを作成します。sp_ADLS_BackupLog ストアド プロシージャは、完全なデータベースまたはトランザクション ログをディスクにバックアップします。AzCopy は、バックアップ ファイルをディスクから Azure BLOB ストレージ コンテナーにコピーします。

  • ジョブを作成する際、ADLS インストーラーから渡された Azure パラメーター、転送/圧縮パラメーター、およびジョブ スケジュール パラメーターを使用します。

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、このストアド プロシージャの署名とパラメーターの一覧と説明が示されています。

sp_ADLS_DestnInstall ストアド プロシージャは、ターゲットでのログ配布のために必要な Azure 資格情報およびジョブを作成することを目的としています。sp_ADLS_DestnInstall は、次のアクションを実行します。

  • ADLS インストーラーによって提供された Azure ストレージ アカウント名およびストレージ アクセス キーを使用して、一意の Azure 資格情報を作成します。

  • LogLocationType=0 の場合、データベース バックアップまたはトランザクション ログ バックアップを Azure BLOB ストレージから復元するための、指定されたパラメーターを使用して sp_ADLS_RestoreLog を起動する単一ステップのジョブを作成します。LogLocationType=1 の場合、AzCopy を起動した後に sp_ADLS_RestoreLog を実行する、2 つのステップから構成されるジョブを作成します。AzCopy は、BLOB ストレージ コンテナーからローカル ディスクにバックアップ ファイルをコピーします。sp_ADLS_RestoreLog ストアド プロシージャは、データベース バックアップまたはトランザクション ログ バックアップをディスクから復元します。

  • ジョブを作成する際、ADLS インストーラーから渡された Azure パラメーター、転送/圧縮パラメーター、およびジョブ スケジュール パラメーターを使用します。

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、このストアド プロシージャの署名とパラメーターの一覧と説明が示されています。

sp_ADLS_BackupLog ストアド プロシージャは、ファイルに適切に名前とシーケンス番号を付けながら完全なデータベースまたはトランザクション ログをバックアップすることを目的としています。名前とシーケンス番号は、ファイルが正しいデータベースに正しい順序で復元されることを保証するうえで重要です。sp_ADLS_BackupLog は、次のアクションを実行します。

  • 指定されたパラメーターを使用して次の手順でバックアップ ステートメントを作成する。

    • 指定された SQL Server インスタンスの最後に成功したバックアップ シーケンス番号とデータベース名を LogBackupInfo テーブルから取得する。

    • 最後のシーケンス番号が null の場合はデータベース バックアップ ステートメントを作成する。それ以外の場合は、シーケンス番号を 1 増やしてログ バックアップ ステートメントを作成する。

    • <DB 名> + "_db_" + [次のシーケンス番号] + ".bak" (完全バックアップの場合) または <DB 名> + "_log_" + [次のシーケンス番号] + ".bak" (ログ バックアップの場合) 形式でバックアップ ファイル名を作成する。

    • 既定で HTTPS を使用する (明示的に指定された場合にのみ HTTP を使用する)。

    • 既定で圧縮を使用する (明示的に指定された場合にのみ圧縮を使用しない)。

    • LogLocationType=1 の場合は Azure BLOB ストレージ URL を作成する。それ以外の場合は、ローカル フォルダー パスを使用する。

  • バックアップを実行する。

  • バックアップの結果を、サーバー名、データベース名、バックアップ ステートメント、および実行日時と共に LogBackupInfo テーブルに記録する (status=1 は成功を暗示します)。

  • エラーが発生した場合、ERROR_NUMBER()ERROR_SEVERITY()ERROR_STATE()ERROR_PROCEDURE()ERROR_LINE()、および ERROR_MESSAGE() の Transact-SQL 関数を使用して取得するエラー情報を OperationErrorInfo テーブルに記録する。

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、このストアド プロシージャの署名とパラメーターの一覧と説明が示されています。

sp_ADLS_RestoreLog ストアド プロシージャは、完全なデータベースまたはトランザクション ログ ファイルを復元することを目的としています。sp_ADLS_RestoreLog は、次のアクションを実行します。

  • 指定されたパラメーターを使用して次の手順で復元ステートメントを作成する。

    • 指定された SQL Server インスタンスの最後に成功した復元シーケンス番号とデータベース名を LogRestoreInfo テーブルから取得する。

    • 最後のシーケンス番号が null の場合はデータベース復元ステートメントを作成する。それ以外の場合は、シーケンス番号を 1 増やしてログ復元ステートメントを作成する。

    • <DB 名> + "_db_" + [次のシーケンス番号] + ".bak" (完全バックアップの場合) または <DB 名> + "_log_" + [次のシーケンス番号] + ".bak" (ログ バックアップの場合) 形式で復元ファイル名を作成する。

    • 既定で HTTPS を使用する (明示的に指定された場合にのみ HTTP を使用する)。

    • LogLocationType=1 の場合は Azure BLOB ストレージ URL を作成する。それ以外の場合は、ローカル フォルダー パスを使用する。

    • 指定された復旧オプションに応じて、復元時に standby、スタンバイ ファイル名、または norecovery を指定する。

    • RESTORE ステートメントを作成し、指定された MOVE オプションを追加する。

  • 復元操作の前に、ターゲット データベースを SINGLE_USER モードにする。

  • ALTER DATABASE の ROLLBACK IMMEDIATE オプションを使用して既存の接続を終了する。

  • 復元操作を実行する。

  • 復元操作後またはエラーが発生した場合にデータベースを MULTI_USER モードにする。

  • 復元操作の結果を、サーバー名、データベース名、バックアップ ステートメント、および実行日時と共に LogBackupInfo テーブルに記録する (status=1 は成功を暗示します)。

  • エラーが発生した場合、ERROR_NUMBER()ERROR_SEVERITY()ERROR_STATE()ERROR_PROCEDURE()ERROR_LINE()、および ERROR_MESSAGE() の関数を使用して取得するエラー情報を OperationErrorInfo テーブルに記録する。

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、このストアド プロシージャの署名とパラメーターの一覧と説明が示されています。

LogBackupInfo テーブルは、それぞれの SQL Server インスタンスおよびデータベースに対するログ バックアップ操作の履歴を格納します。この履歴には、サーバー名、データベース名、ストレージ アカウント名、実行された完全な Transact-SQL ステートメント、バックアップ ファイルの完全なパスなどの詳細が含まれます。このテーブルは、サーバー名とデータベース名のそれぞれの組み合わせに対して、最後に成功したバックアップのシーケンス番号を格納します。

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、このテーブルの定義と列の説明が示されています。

LogRestoreInfo テーブルは、それぞれの SQL Server インスタンスおよびデータベースに対するログ復元操作の履歴を格納します。この履歴には、サーバー名、データベース名、ストレージ アカウント名、実行された完全な Transact-SQL ステートメント、それぞれの復元されたファイルの完全なパスなどの詳細が含まれます。このテーブルは、サーバー名とデータベース名のそれぞれの組み合わせに対して、最後に成功した復元操作のシーケンス番号を格納します。

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、このテーブルの定義と列の説明が示されています。

OperationErrorInfo テーブルは、失敗したバックアップまたは復元操作のエラー情報を格納します。OperationErrorInfoId 列を使用して OperationErrorInfo テーブルを LogBackupInfo テーブルまたは LogRestoreInfo テーブルと結合すると、エラーの原因となった操作の詳細を取得できます。このテーブルの他の列には、エラーの発生直後に Transact-SQL ERROR 関数を呼び出したときに返される値が格納されます。

Documentation for Tables and Stored Procedures (テーブルとストアド プロシージャに関するドキュメント)』には、このテーブルの定義と列の説明が示されています。

組み込みのログ配布機能は、一定の時間にわたってバックアップまたは復元操作が実行されなかった場合にその旨を通知する機能を提供します。ソリューション コンポーネントはアラート メカニズムを備えていませんが、最後に成功したバックアップまたは復元操作の履歴テーブルを調べて、保留されているバックアップおよび復元操作に関する情報を見つけるスケジュールされたジョブを作成できます。

ソリューションには、復元されたログ ファイルのクリーンアップ/削除メカニズムは用意されていません。Transact-SQL を使用して BLOB ストレージからファイルを直接削除することはできないため、Representational State Transfer (REST) API を使用して BLOB ストレージから古いログ ファイルを削除するための .NET プログラムを作成することを検討してください。

ログ配布を使用する場合、プライマリ サイトが障害の影響を受けたときのプライマリ サイトから障害復旧サイトへの自動フェールオーバーは用意されていません。このフェールオーバーは、手動で開始するか、スクリプト、ツール、またはアプリケーション ロジックを使用して自動的に実行する必要があります。プライマリ データベースで障害を検出した場合は、できる限り低い RPO を実現するために、プライマリ サイトの使用可能な残りのすべての (セカンダリ サイトにまだ適用されていない) トランザクション ログ バックアップを障害復旧サイトの SQL Server インスタンス上で復元する必要があります。これらのトランザクション ログのアクセスと復元に要する時間が RTO に影響を与えます。障害復旧データベースに対して可能な復旧モードを次に示します。

  • NORECOVERY。ログ配布によって障害復旧サイトの SQL Server データベースが NORECOVERY モードになると、障害復旧サイトで SQL Server データベースの読み取りまたは書き込みを行うことができなくなります。ただし、トランザクション ログは引き続き復元できます。フェールオーバー後、障害復旧データベースを RECOVERY モードに切り替える必要があります。

  • STANDBY。このモードでは、障害復旧サイトの SQL Server インスタンスは読み取り専用になります。このモードでは読み取りクエリに対する RTO が低くなりますが、データベースは書き込みトランザクションを受け付けません。また、アクティブな接続が存在している間はログを復元できません。このモードでは、すべての書き込みクエリは失敗します。そのため、このモードでは、書き込みクエリのサービスに対して設定されたどのような RTO も満たすことはできません。このモードは、プライマリ サイトの修復中に障害復旧サイトでの読み取りクエリを一時的に許可する方法として検討してください。

  • RECOVERY。障害復旧サイトの SQL Server データベースが復旧されたとき、SQL Server は、適用された最後のトランザクション ログ バックアップを使用して、すべてのコミットされたトランザクションをロールフォワードし、コミットされていないトランザクションをロールバックします。その後、データベースに対して読み取りおよび書き込みアクティビティを行うことができるようになります。ターゲット データベースをどれだけ迅速に復旧できるかは、復元されていないトランザクション ログにアクセスして復元するのに要する時間に左右されます。即時フェールオーバー (低 RTO) がデータ損失を最小化するニーズよりも優先される場合は、残りのトランザクション ログを復元することなく、障害復旧サイトで即時復旧を実行できます。

ゼロ RPO を実現するには、障害復旧データベースを復旧する前にすべてのログ バックアップを障害復旧サイトに復元する必要があります。これは、障害にもかかわらずプライマリ データベースと BLOB ストレージの場所が利用可能な、限定的な障害シナリオでのみ実現できます。このシナリオでは、最後のログ末尾のバックアップをプライマリ サイト上で実行でき、障害復旧サイトで復元の対象となっているすべての残りのログ ファイルにアクセスできます。ログ末尾のバックアップの目的は、前回の完全なログ バックアップ以降に発生したすべての未処理のトランザクションをキャプチャすることにあります。

インストールした SQL エージェント ジョブおよびストアド プロシージャを使用して、計画フェールオーバーを実行できます。

プライマリ サイトの SQL Server インスタンスとストレージが利用可能な限定的な障害シナリオでは、自動化されたログ配布を停止し、手動バックアップおよびログ末尾のバックアップを 1 回以上実行する必要があります。

特定のデータベースに対してログ配布を一時的に停止するには、SQL Server Management Studio または Transact-SQL sp_update_job ストアド プロシージャを使用して、ADLS_Job_Source_<DBName> ストアド プロシージャを無効にします。たとえば、次の Transact-SQL ステートメントは、"test" という名前のデータベースの ADLS コピーおよび復元ジョブを無効にします。

exec sp_update_job @job_name = N'ADLS_Job_Source_test', @enabled = 0

SQL Server Management Studio からジョブを無効にすることもできます。セカンダリ サイトへの永続的なカットオーバーの場合は、ジョブを削除できます。

ジョブを無効にした後で手動ログ バックアップを順番に実行するには、sp_ADLS_BackupLog ストアド プロシージャを実行します。たとえば、次のステートメントは、SQL Server 資格情報 "mycred"、ストレージ アカウント "mystorageaccount"、および BLOB コンテナー "backup" を使用して、BLOB ストレージから "test" という名前のデータベースの手動 (シーケンス番号が付けられた) ログ バックアップを実行します。

exec sp_ADLS_BackupLog 0, 'test', 'mycred', 'mystorageaccount', 'backup'

現在、ADLS_ ストアド プロシージャには、ログ末尾のバックアップを実行するためのオプションはありません。これを実装する方法については、「トランザクション ログの末尾をバックアップする方法」を参照してください。

ログ末尾のバックアップが正常に完了した後、ログ末尾のバックアップを障害復旧サイトに手動でコピーします。

障害が限定的であろうとフルスケールであろうと、どこかの時点で障害復旧サイトへのフェールオーバーが必要になる場合があります。手順としては、障害復旧サイトで復元ジョブを無効化 (および削除) した後、(該当する場合はログ末尾のバックアップも含めて) すべての残りのログを復元して、データベースを復旧します。

特定のデータベースに対してログ配布を無効にするには、SQL Server Management Studio または Transact-SQL sp_update_job ストアド プロシージャを使用して、ADLS_Job_Destn<DBName> ストアド プロシージャを無効にします。たとえば、次の Transact-SQL ステートメントは、"test" という名前のデータベースの ADLS コピーおよび復元ジョブを無効にします。

exec sp_update_job @job_name = N'ADLS_Job_Destn_test', @enabled = 0

SQL Server Management Studio からジョブを無効にすることもできます。セカンダリ サイトへの永続的なカットオーバーの場合は、ジョブを削除できます。

(SQL Server エージェント ジョブを無効にした後) ターゲット上で 1 つまたは複数のログ ファイルを手動で順に復元するには、ストアド プロシージャ sp_ADLS_RestoreLog を実行します。たとえば、次のステートメントを使用すると、SQL Server 資格情報 "mycred"、ストレージ アカウント "mystorageaccount"、および BLOB コンテナー "backup" を使用して、BLOB ストレージから "test" という名前のデータベースの次のログ バックアップを手動で復元できます。この例では、復元されたデータベースはスタンバイ モードになり、スタンバイ ファイルは C:\backup に配置されます。

exec sp_ADLS_RestoreLog 0, 'test', 'mycred', 'mystorageaccount', 'backup', 1, 'C:\backup'

復元操作の結果は、LogRestoreInfo テーブルに記録されます。エラーが発生した場合、エラーは OperationErrorInfo テーブルに記録されます。

ターゲット データベースを復旧モードにするには、次の Transact-SQL ステートメントを実行します。

restore  database <DatabaseName> with recovery

プライマリ サイトで障害が発生し、障害復旧サイトへのフェールオーバーが行われたとします。やがて元のプライマリ サイトが修復され、使用準備が整ったとします。この状況において、障害復旧サイト (現在のプライマリ サイト) を元のプライマリ サイトに切り替えたいとします。そのためには、カスタム ログ配布コンポーネントを使用して、最初に逆方向のログ配布を設定し、その後適切なときに計画フェールオーバーを実行します。逆方向の操作を実行する前に、既存のログ配布ジョブを削除し、次に SQL Server インスタンスと目的のデータベースの LogRestoreInfo および LogBackupInfo テーブルのエントリをバックアップおよび削除することをお勧めします。

切り替えを行うには、元のプライマリ サイトにバックアップを転送して復元することに加え、障害復旧サイト (現在のプライマリ サイト) での完全なデータベース バックアップの実行が必要になります。データベースのサイズが大きい場合、この操作には時間がかかります。元のプライマリ サイトからのフェールオーバー中に元のプライマリ サイトのログ末尾のバックアップを行い、それを障害復旧サイトに復元しておけば、切り替え中に完全バックアップと転送を行わずに済みます。その場合、元のプライマリ サイトへのフェールオーバー後に作成された障害復旧サイト (現在のプライマリ サイト) のログ バックアップだけを復元すれば十分です。現在、ADLS コンポーネントには、ログ バックアップのみを転送して元のプライマリへの切り替えを自動化する方法は用意されていません。

このドキュメントで説明した geo DR 戦略では、データベースおよびトランザクション ログ バックアップを Azure BLOB ストレージに格納することを想定しています。Microsoft は、最近、この目的に使用できるツールをリリースしました。Microsoft SQL Server Backup to Azure Tool を使用すると、Azure BLOB ストレージにバックアップできるほか、ローカルまたはクラウドに格納されている SQL Server バックアップを暗号化および圧縮できます。詳細については、Microsoft SQL Server Backup to Azure Tool に関するページを参照してください。現在、このツールにはバックアップを障害復旧サイトに復元する機能が用意されていないため、その操作を行うにはカスタム アプローチを実装する必要があります。

サービスとしての Azure インフラストラクチャ上の SQL Server の geo DR は、カスタマイズされたログ配布アプローチを使用して実現できます。このアプローチを実装するために使用された .NET コードと Transact SQL スクリプトのサンプルを参照して、要件に合わせてカスタマイズを行ってください。

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2014 Microsoft