既存のAlwaysOn可用性グループ環境でSQL Serverログ配布を構成する方法

本記事では、ディザスターリカバリー(DR)ソリューションであるログ配布(Log Shipping)を、既にMicrosoft® SQL Server®のAlwaysOn構成が設定されているデータベースに対して構築する方法について解説します。

はじめに

AlwaysOn可用性グループ(AG)は、データベースミラーリングに代わるエンタープライズレベルの高可用性・災害対策ソリューションです。SQL Server 2012(11.x)で導入されたAlwaysOn AGは、エンタープライズ環境における一連のユーザーデータベースの可用性を最大化します。AGは「可用性データベース」と呼ばれる個別のユーザーデータベース群をまとめてフェイルオーバーさせる環境をサポートし、読み書き可能なプライマリデータベースと、それに対応する最大8セットのセカンダリデータベースを保持できます。さらにオプションとして、セカンダリデータベースを読み取り専用アクセスや一部のバックアップ操作に利用することも可能です。

一方、SQL Serverのログ配布機能を使用すると、プライマリサーバーインスタンス上のプライマリデータベースからトランザクションログバックアップを自動的に送信し、別々のセカンダリサーバーインスタンス上にある1つ以上のセカンダリデータベースへ適用できます。トランザクションログバックアップは、各セカンダリデータベースに対して個別に適用されます。

AlwaysOn環境でログ配布が必要になる理由

ここで、プライマリレプリカサーバーとセカンダリレプリカ間でAlwaysOnが構成されており、メインデータセンターで運用されている状況を想定します。必要なWindows Serverフェールオーバークラスター(WSFC)構成をDRサイトまで拡張できない場合には、ログ配布の利用を検討する必要があります。その理由として以下のようなケースが挙げられます。

• インフラストラクチャや人員の制約により、異なるサイト間でWSFC構成を維持できない。
• DRサイトのターゲットサーバーが、すでに別のWSFC構成の一部であるため、WSFC構成に組み込めない。
• 復旧ポイント目標(RPO)および復旧時間目標(RTO)に関するサービスレベル契約(SLA)により、人的ミスからの迅速な復旧が求められており、それを実現するにはHA/DR戦略の一環として、トランザクションログバックアップを遅延させて復元する仕組みが必要である。

このような場合、DRサイトにあるターゲットサーバーへ、メインサイトの現在のプライマリで実行されたバックアップからトランザクションログをログ配布によって供給する必要があります。

ログ配布を利用するための前提条件

ログ配布を設定する前に、以下の前提条件を満たしていることを確認してください。

• プライマリデータベースは、完全復旧モデルまたは一括ログ復旧モデルを使用している必要があります。単純復旧モデルに変更すると、ログ配布は機能しなくなります。
• ログ配布を構成する前に、トランザクションログバックアップをセカンダリサーバーから参照できるよう、共有パスを作成しておく必要があります。
• ログ配布のストアドプロシージャを実行するには、sysadmin固定サーバーロールのメンバーシップが必要です。
• バックアップ用の共有パスには、SQL Serverサービスアカウントに対する読み取り・書き込み権限を付与しておく必要があります。

ログ配布DRソリューションの構成例

この例では、プライマリレプリカサーバー「PRIMEHEAD」とセカンダリレプリカ「HEAD2」の間で、既にAlwaysOnが構成されているものとします。

以降では、既にAlwaysOn AGの一部となっているデータベースに対してログ配布を構成する手順を、ステップごとに説明します。

ステップ1

AdventureWorks2014データベースについて、PRIMEHEADとDRサーバーHEAD3の間でログ配布を構成します。

ログ配布を構成する際には、AdventureWorks2014データベースの完全バックアップを取得し、HEAD3上にNORECOVERYオプションで復元しておきます。また、LSCopy(ログ配布)ジョブが使用するログバックアップを格納するための共有フォルダをPRIMEHEAD上に作成します。

ステップ2

PRIMEHEAD上でデータベースを右クリックし、[プロパティ]を選択します。左側の[トランザクション ログ配布]オプションをクリックし、次に[これをログ配布構成のプライマリ データベースとして有効にする]チェックボックスをオンにします。

ステップ3

[バックアップの設定]をクリックし、LS Backupオプションを構成します。LS Backup用のネットワーク共有パスを選択します。

ステップ4

この時点で、要件に応じてLS Backupのスケジュールを変更することもできます。ただし、このシナリオではデフォルト設定を使用します。

ステップ5

DRサーバーを追加するために、[追加]をクリックします。

ステップ6

[接続]をクリックして、DRサーバーであるHEAD3に接続します。

ステップ7

[セカンダリ データベースの初期化]タブで、3番目のオプションを選択します。これは、データベースが既にHEAD3上で初期化されているためです。

ステップ8

[ファイルのコピー]タブをクリックし、[コピーしたファイルのコピー先フォルダー]ボックスに、トランザクションログバックアップのコピー先パスを入力します。このシナリオでは、パスとしてC:\LSCopyAlwaysOnを使用します。

ステップ9

[トランザクション ログの復元]タブで、[バックアップ復元時のデータベース状態]として、[復旧なしモード]または[スタンバイ モード]のいずれかを選択します。

この例では[復旧なしモード]を選択しています。これは、DRデータベースがエンドユーザーからアクセスできない状態であることを意味します。[スタンバイ モード]を選択した場合は、DRデータベースを読み取り専用モードでエンドユーザーに提供できます。

ステップ10

[OK]をクリックすると、ログ配布が開始されます。

ステップ11

ログ配布の状態を確認するには、DRサーバーHEAD3のインスタンスを右クリックし、[レポート]→[標準レポート]→[トランザクション ログ配布の状態]を選択します。正常な画面が表示されれば、ログ配布は健全に動作しています。

ここで注意が必要なのは、PRIMEHEADとHEAD2の間でAGのフェイルオーバーが発生すると、AGの仕様に合わせて再構成するまでログ配布が中断されるという点です。

そこで、HEAD2からHEAD3へのログ配布を構成します。こうすることで、将来AGレプリカ間でフェイルオーバーが発生しても、ログ配布機能には影響しません。どちらのレプリカがプライマリとして稼働していても、ログバックアップは常に同じパスまたは場所で実行されるためです。

まず、レプリカ間でフェイルオーバーを実行します。フェイルオーバーを開始する前に、以下の手順を完了させてください。

1. プライマリレプリカでLSバックアップジョブを実行し、その後ジョブを無効化する。
2. セカンダリレプリカでLSコピージョブとLS復元ジョブを実行し、その後ジョブを無効化する。

これを行うには、AGを右クリックしてフェイルオーバーオプションを選択します。または、以下のT-SQLコマンドを使用して、AGのフェイルオーバーを手動でトリガーすることもできます。

USE master;
GO

ALTER AVAILABILITY GROUP [AGName] FAILOVER
GO

フェイルオーバーが完了すると、ウィンドウが表示されます。

ステップ12

PRIMEHEADとHEAD2の間でAGフェイルオーバーが完了すると、現在のプライマリインスタンスはHEAD2になります。

同じ手順に従って、現在のプライマリサーバー(ノード)であるHEAD2からDRサーバーHEAD3へのログ配布を構成します。ログ配布の構成時には、PRIMEHEADとHEAD3の間のLS構成で使用したものと同じ共有パス\\Avail2017\lsbackupを選択してください。

ステップ13

現在のプライマリであるHEAD2とHEAD3の間のログ配布が完了すると、HEAD2上にLSバックアップジョブが作成され、HEAD3上にもう一組のLSコピージョブとLS復元ジョブが作成されます。

再度、AGレプリカ間でフェイルオーバーを実行します。フェイルオーバーを開始する前に、必ず以下の手順を完了させてください。

1. プライマリ(HEAD2)でLSバックアップジョブを実行し、その後ジョブを無効化する。
2. セカンダリ(HEAD3)でLSコピージョブとLS復元ジョブを実行し、その後ジョブを無効化する。

ステップ14

最終的なフェイルオーバーの後、現在のプライマリはPRIMEHEAD、セカンダリレプリカはHEAD2、DRサーバーはHEAD3となります。プライマリとセカンダリの両方のサーバーにLSバックアップジョブが存在するため、現在のプライマリからのみログバックアップが取得されるように、PRIMEHEADとHEAD2の両方でLSバックアップジョブを修正する必要があります。

そのためには、ジョブのステップ1に以下のコードを追加します。

Declare @dbname as varchar(20)
Set @dbname='AdventureWorks2014'
If sys.fn_hadr_backup_is_preferred_replica (@dbname)<>1
begin
RAISERROR (50005,-- Message id,
           16, -- Severity,
           1, --State,
           N'This is not the primary server backup is rolled back');
end

上記の変更を行うと、LSバックアップジョブはセカンダリサーバー上では失敗する一方、プライマリサーバー上では正常に実行されるようになります。

ステップ15

DRサーバーであるHEAD3には2組のLSコピージョブとLS復元ジョブが存在するため、同時に実行されるのは1組だけになるようにする必要があります。HEAD2とHEAD3の間でログ配布を構成した際に作成されたジョブを有効のまま残し、もう一方の組のジョブを無効化してください。

以上で、既にAlwaysOn AGの一部となっているデータベースに対するログ配布の構成が完了しました。どのサーバーがプライマリサーバーとして稼働していても、ログ配布は同期された状態を保ちます。

注意: 本番環境に変更を加える前に、必ずテスト環境で検証することを強くお勧めします。本番環境にこのソリューションを実装する前に、まずテスト環境でこの構成を試してください。

検証

• バックアップジョブが現在のプライマリレプリカ上で正常に実行されていることを確認する。
• バックアップパスが共有パスと一致していることを確認する。
• HEAD2からHEAD3へのLS構成時に作成されたコピージョブと復元ジョブが、DRサーバー上で正しく実行されていることを確認する。
• 標準レポートの[トランザクション ログ配布の状態]を確認する。

まとめ

高可用性データベースに対してログ配布を構成することで、別のデータセンターにDRサーバーを設置できます。この構成は災害発生時のビジネス継続性を確保し、たとえ他のデータセンターのサーバーが影響を受けたとしても、最小限の手作業で業務への影響を抑えることができます。

専門家による管理・運用で環境を最適化

Rackspaceのアプリケーションサービス(RAS)の専門家は、幅広いアプリケーションポートフォリオにわたり、以下のようなプロフェッショナルサービスおよびマネージドサービスを提供しています。

>eCommerceおよびデジタルエクスペリエンスプラットフォーム
• エンタープライズリソースプランニング(ERP)
• ビジネスインテリジェンス
• Salesforce顧客関係管理(CRM)
• データベース
• メールホスティングと生産性向上ツール

私たちが提供する価値は以下の通りです。

• 中立的な専門知識: 即座に価値をもたらす機能に焦点を当て、モダナイゼーションの道のりをシンプルにし、ガイドします。
• Fanatical Experience™: 「プロセスファースト、テクノロジーセカンド®」のアプローチと専任のテクニカルサポートを組み合わせ、包括的なソリューションを提供します。
• 比類ないポートフォリオ: 豊富なクラウド経験を活かし、適切なクラウド上に適切なテクノロジーを選定・展開できるよう支援します。
• アジャイルなデリバリー: お客様の現在地に合わせて伴走し、私たちの成功をお客様の成功と一致させます。