ビジネス継続性とデータベースの復旧 - SQL Server

[アーティクル]
04/26/2023

適用対象: SQL Server 2016 (13.x) 以降のバージョン

この記事では、Windows と Linux 上の SQL Server での高可用性とディザスターリカバリーのためのビジネス継続性ソリューションの概要を説明します。

SQL Server を展開するすべての人が行う必要がある 1 つの共通タスクは、すべてのミッションクリティカルな SQL Server インスタンスとそれらに含まれるデータベースを、ビジネスおよびエンドユーザーが必要とするときに (9 時から 5 時であろうと、24 時間であろうと) 使えるようにすることです。目標は、最小限の中断または中断なく、ビジネスを継続させることです。この概念は、"ビジネス継続性" とも呼ばれます。

SQL Server 2017 (14.x) では、多くの新機能の導入と、既存機能への強化が行われ、そのいくつかは可用性に対するものでした。 SQL Server 2017 (14.x) の最大の補強は、Linux ディストリビューションでの SQL Server のサポートでした。 SQL Server でのすべての新機能の一覧については、次の記事をご覧ください。

この記事では、SQL Server 2017 (14.x) 以降のバージョンでの可用性シナリオと、新規および強化された可用性機能について重点的に取り上げます。シナリオには、Windows Server と Linux の両方にまたがって SQL Server を展開できるハイブリッドなものと、データベースの読み取り可能なコピーの数を増やすことができるものが含まれます。

この記事では、SQL Server 以外の可用性オプション (仮想化によって提供されるものなど) については扱いませんが、ここで説明している内容はすべて、パブリッククラウド内であれ、オンプレミスのハイパーバイザーサーバーでホストされる場合であれ、ゲスト仮想マシン内での SQL Server のインストールに適用されます。

可用性機能を使用した SQL Server のシナリオ

Always On 可用性グループ、Always On フェールオーバークラスターインスタンス、ログ配布は、さまざまな方法で使用でき、必ずしも可用性を高めることだけが目的ではありません。可用性機能を使用できる 4 つの主な方法があります。

高可用性
障害復旧
移行とアップグレード
1 つ以上のデータベースの読み取り可能なコピーのスケールアウト

以下のセクションでは、その特定のシナリオに使用できる関連機能について説明します。 SQL Server レプリケーションの機能については、取り上げません。これは Always On の傘下の可用性機能としては正式に指定されていませんが、特定のシナリオでデータに冗長性を持たせるために SQL Server のレプリケーションがよく使用されます。 SQL Server on Linux では、マージレプリケーションはサポートされていません。詳細については、「Linux 上の SQL Server レプリケーション」を参照してください。

重要

SQL Server の可用性機能は、可用性ソリューションの最も基本的なビルディングブロックである、堅牢で十分にテストされたバックアップと復元方法を持つという要件に取って代わるものではありません。

高可用性

データセンターで局所的に、またはクラウド内の 1 つのリージョンで問題が発生した場合に、SQL Server インスタンスまたはデータベースを使用できることを保証することが重要です。このセクションでは、SQL Server の可用性機能がそのタスクでどのように役立つかを説明します。記載されているすべての機能は、Windows Server と Linux の両方で使用できます。

可用性グループ

SQL Server 2012 (11.x) で導入された可用性グループ (AG) は、データベースの各トランザクションを、そのデータベースの特別な状態のコピーが含まれる別のインスタンス ("レプリカ") に送信することによって、データベースレベルの保護を提供します。 AG は、Standard または Enterprise エディションに展開できます。 AG に参加しているインスタンスは、スタンドアロンまたはフェールオーバークラスターインスタンス (FCI、次のセクションで説明) のいずれかにすることができます。トランザクションは、発生したときにレプリカに送信されるため、目標復旧時点と目標復旧時間の要件がより低い AG が推奨されます。レプリカ間のデータ移動は、同期または非同期で行うことができ、Enterprise エディションでは最大 3 つのレプリカ (プライマリを含む) の同期が許可されます。 AG には、プライマリレプリカにあるデータベースの完全な読み取り/書き込みコピーが 1 つありますが、すべてのセカンダリレプリカはエンドユーザーやアプリケーションから直接トランザクションを受け取れません。

注意

Always On は SQL Server での可用性機能の総称で、AG と FCI の両方が含まれます。 Always On は、AG 機能の名前ではありません。

SQL Server 2022 (16.x) より前の AG では、データベースレベルのみが提供され、インスタンスレベルの保護は提供されません。トランザクションログにキャプチャされていないものや、データベースに構成されていないものはすべて、セカンダリレプリカごとに手動で同期する必要があります。手動で同期する必要があるオブジェクトの例としては、インスタンスレベル、リンクサーバー、および SQL Server エージェントジョブでのログインがあります。

SQL Server 2022 (16.x) 以降では、ユーザーは、インスタンスレベルに加えて、AG レベルでユーザー、ログイン、アクセス許可、SQL Server エージェントジョブなどのメタデータオブジェクトを管理できます。詳しくは、包含可用性グループに関する記事をご覧ください。

AG には、"リスナー" と呼ばれる別のコンポーネントもあります。これにより、アプリケーションとエンドユーザーは、プライマリレプリカをホストしている SQL Server インスタンスがわからなくても接続できます。各 AG には、独自のリスナーがあります。リスナーの実装は、Windows Server と Linux ではわずかに異なりますが、提供される機能とその使用方法は同じです。次の図は、Windows Server フェールオーバークラスター (WSFC) を使っている Windows Server ベースの AG を示したものです。 OS レイヤーでの基になるクラスターは、Linux または Windows Server 上にあるかどうかに関係なく、可用性に必要です。この例では、基になるクラスターが WSFC である 2 つのサーバー ("ノード") の単純な構成を示します。

単純な可用性グループの図。

レプリカ数に関しては、Standard と Enterprise エディションで最大数が異なります。 Standard エディションの AG (基本的な可用性グループ) は、AG 内で 2 つのレプリカ (プライマリとセカンダリ) と 1 つのデータベースのみをサポートします。 Enterprise エディションは、1 つの AG に複数のデータベースを構成できるだけでなく、最大 9 つのレプリカ (1 つのプライマリ、8 つのセカンダリ) を持つこともできます。 Enterprise Edition では、読み取り可能なセカンダリレプリカ、セカンダリレプリカからバックアップを作成するなど、その他の利点ももたらされます。

注意

SQL Server 2012 (11.x) で非推奨とされたデータベースミラーリングは、Linux バージョンの SQL Server では使用できず、追加される予定もありません。まだデータベースミラーリングを使っているお客様は、データベースミラーリングの後継である AG への移行を計画する必要があります。

可用性に関しては、AG は自動または手動のフェールオーバーを提供できます。自動フェールオーバーは、同期データ移動が構成されていて、プライマリとセカンダリのレプリカ上のデータベースが同期状態にある場合に発生する可能性があります。リスナーが使われていて、アプリケーションが新しいバージョンの .NET Framework (更新プログラムが提供された 3.5、または 4.0 以降) を使っている限り、フェールオーバーは、リスナーが利用される場合はエンドユーザーに対する影響が最小限になるか、ないように処理されるはずです。セカンダリレプリカを新しいプライマリレプリカにするフェールオーバーは、自動または手動に構成でき、通常は数秒で測定されます。

次の一覧は、Windows Server と Linux での AG に関するいくつかの違いを示したものです。

Linux と Windows Server での基になるクラスターの動作の違いにより、AG のすべてのフェールオーバー (手動または自動) は、Linux 上のクラスターを介して行われます。 Windows Server ベースの AG の展開では、手動フェールオーバーは SQL Server 経由で行う必要があります。自動フェールオーバーは、Windows Server でも Linux でも基になるクラスターによって処理されます。
SQL Server on Linux の場合は、少なくとも 3 つのレプリカで AG を構成することをお勧めします。これは、基になるクラスタリングの動作方法に起因します。
Linux では、各リスナーで使用される共通名は、Windows Server のようにクラスターではなく、DNS で定義されます。

SQL Server 2017 (14.x) 以降の AG には、いくつかの新機能と機能強化があります。

クラスターの種類
REQUIRED_SECONDARIES_TO_COMMIT
Windows Server ベースの構成に対する Microsoft 分散トランザクションコーディネーター (DTC) サポートの強化
読み取り専用データベースに対するスケールアウトシナリオの追加 (この記事内で後ほど説明)

可用性グループのクラスターの種類

Windows Server でのクラスタリングの組み込みの可用性フォームは、フェールオーバークラスタリングと呼ばれる機能を通じて有効化されます。これにより、AG または FCI で使用される WSFC を構築できます。 AG と FCI 用の統合は、SQL Server に付属するクラスター対応のリソース DLL で提供されます。

SQL Server on Linux では、複数のクラスタリングテクノロジがサポートされています。 Microsoft は SQL Server コンポーネントをサポートし、パートナーは関連するクラスタリングテクノロジをサポートしています。たとえば、SQL Server on Linux では、Pacemaker と共に、HPE Serviceguard と DH2i DxEnterprise がクラスターソリューションとしてサポートされています。

Windows ベースのフェールオーバークラスターと Linux クラスターソリューションは、相違点より類似点の方が多くあります。どちらも個別のサーバーを使用してそれらを構成で結合し、可用性を提供する方法を提供し、リソース、制約 (異なる方法で実装されている場合でも)、フェールオーバーなどの概念を持っています。

たとえば、自動フェールオーバーなど、AG と FCI の両方の構成で Pacemaker をサポートするために Microsoft が提供している Pacemaker 用の mssql-server-ha パッケージは、WSFC でのリソース DLL に似ていますが、まったく同じではありません。 WSFC と Pacemaker の違いの 1 つは、Pacemaker にはネットワーク名リソースがないことです。これは、WSFC でリスナーの名前 (または FCI の名前) を抽象化するのに役立つコンポーネントです。 DNS は、その名前解決を Linux 上で提供しています。

クラスタースタックの違いにより、SQL Server は WSFC によってネイティブに処理されるメタデータの一部を処理する必要があるため、AG に対していくつかの変更を行う必要があります。そのような重要な変更の 1 つは、可用性グループに対する "クラスターの種類" の導入です。これは、sys.availability_groups の cluster_type 列と cluster_type_desc 列に格納されます。次の 3 つのクラスターの種類があります。

WSFC
外部
なし

高可用性を必要とするすべての AG で、基になるクラスターを使う必要があり、SQL Server 2017 (14.x) 以降のバージョンでは、これは WSFC または Linux クラスタリングエージェントを意味します。基になる WSFC を使う Windows Server ベースの AG の場合は、既定のクラスターの種類が WSFC なので、設定する必要はありません。 Linux ベースの AG の場合は、AG を作成するときに、クラスターの種類を External に設定する必要があります。 Linux での外部クラスターソリューションとの統合は、AG の作成後に構成されますが、WSFC では作成時に行われます。

None のクラスターの種類は、Windows Server と Linux 両方の AG で使用できます。クラスターの種類を None に設定することは、AG で基になるクラスターが必要ないことを意味します。つまり、SQL Server 2017 (14.x) は、クラスターなしで AG をサポートする最初の SQL Server のバージョンですが、そのトレードオフとして、この構成は高可用性ソリューションとしてサポートされません。

重要

SQL Server 2017 (14.x) 以降では、作成後に AG のクラスターの種類を変更することはできません。つまり、AG を None から External または WSFC (またはその逆) に切り替えることはできません。

データベースの読み取り専用コピーをさらに追加することだけを検討しているユーザー、または移行やアップグレードを提供している AG は欲しいが、基になるクラスターやレプリケーションにより複雑さが増すことを好まないユーザーにとっては、クラスターの種類が None の AG が、最適なソリューションです。詳しくは、「移行とアップグレード」と「読み取りスケール」のセクションをご覧ください。

次のスクリーンショットは、SQL Server Management Studio (SSMS) での異なるクラスターの種類のサポートを示しています。 17.1 以降のバージョンを実行する必要があります。次のスクリーンショットはバージョン 17.2 のものです。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 (13.x) では、Enterprise エディションでのサポートされる同期レプリカの数が 2 つから 3 つに増えました。しかし、1 つのセカンダリレプリカを同期したものの、他のレプリカで問題が発生した場合、動作を制御する方法がなく、プライマリレプリカに誤動作しているレプリカを待機するか、先に進むかを指示できませんでした。つまり、セカンダリレプリカが同期されていない状態 (セカンダリレプリカ上でデータの損失が発生している) でも、ある時点でプライマリレプリカが書き込みトラフィックを受信し続けることになります。 SQL Server 2017 (14.x) 以降では、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を使用して同期レプリカがある場合の動作を制御できます。このオプションの動作は次のとおりです。

指定可能な 3 つの値は、0、1、2 です
値は同期する必要があるセカンダリレプリカの数で、データの損失、AG の可用性、およびフェールオーバーに影響します
WSFC およびクラスターの種類 None の場合、既定値は 0 で、手動で 1 または 2 に設定できます
クラスターの種類が External の場合、既定では、クラスターメカニズムによってこの値が設定され、手動でオーバーライドできます。同期レプリカが 3 つの場合は、既定値は 1 になります。

Linux では、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT の値はクラスター内の AG リソースで構成されます。 Windows では、Transact-SQL を使って設定します。

0 より大きい値は、より高いデータ保護を提供します。これは、必要な数のセカンダリレプリカを使用できない場合は、それが解決されるまでプライマリを使用できないためです。必要な数のセカンダリレプリカが適切な状態でない場合、自動フェールオーバーが行われないため、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT はフェールオーバーの動作にも影響します。 Linux では、値 0 は自動フェールオーバーを許可しないため、Linux では、自動フェールオーバーで同期を使用する場合は、自動フェールオーバーを実現するため 0 より大きい値を設定する必要があります。 Windows Server での 0 は、SQL Server 2016 (13.x) 以前での動作です。

Microsoft 分散トランザクションコーディネーターのサポートの強化

SQL Server 2016 (13.x) より前では、表面下の DTC を使用する分散トランザクションを必要とするアプリケーションの SQL Server での可用性を取得する唯一の方法は、FCI を展開することでした。分散トランザクションは、次の 2 つのいずれかの方法で実行できます。

同じ SQL Server インスタンスで複数のデータベースにまたがるトランザクション
複数の SQL Server インスタンスにまたがる、または場合によっては SQL Server 以外のデータソースが関与するトランザクション

SQL Server 2016 (13.x) では、後者のシナリオをカバーする AG で DTC の部分的なサポートが導入されました。 SQL Server 2017 (14.x) により、DTC を使用した両方のシナリオがサポートされるようになりました。

SQL Server 2017 (14.x) 以降のバージョンでは、AG を作成した後でも DTC サポートを追加できます。 SQL Server 2016 (13.x) では、AG で DTC のサポートを有効にできるのは、AG の作成時のみです。

フェールオーバークラスターインスタンス

クラスター化されたインストールは、SQL Server バージョン 6.5 以降の機能です。 FCI は、インスタンスと呼ばれる SQL Server のインストール全体の可用性を実現する実証済みの方法です。つまり、基になるサーバーに問題が生じると、データベース、SQL Server エージェントジョブ、リンクサーバーなど、インスタンス内のすべてのものが別のサーバーに移動します。すべての FCI には、何らかの共有ストレージが必要です。ネットワーク経由で提供されるものでもかまいません。 FCI のリソースを実行および所有できるのは、一度に 1 つのノードのみです。次の図は、FCI を所有するクラスターの最初のノードを示しています。これは、それに関連付けられた共有ストレージリソースを所有 (ストレージへの実線で示されています) していることも意味します。

フェールオーバークラスターインスタンスの図。

フェールオーバー後は、所有権は次の図にように変更されます。

フェールオーバー後のフェールオーバークラスターインスタンスの図。

FCI ではデータ損失は発生しませんが、データのコピーが 1 つ存在するため、基になる共有ストレージが単一障害点になります。 FCI は多くの場合、データベースの冗長コピーを持つために、AG やログ配布などの別の可用性メソッドと組み合わされます。展開される追加の方法では、FCI と物理的に分離したストレージを使用してください。 FCI が別のノードにフェールオーバーすると、1 つのノードで停止してから別のノードで開始します。これはサーバーの電源をオフにしてからオンにするのと似ています。 FCI は、通常の復旧プロセスを行います。つまり、ロールフォワードする必要があるすべてのトランザクションと、完了していないすべてのトランザクションがロールバックされます。したがって、データベースは、データポイントから障害または手動フェールオーバーの時点まで整合性があるため、データ損失が生じません。データベースは、復旧が完了しないと利用できないため、復旧時間はさまざまな要因によって異なり、通常は AG のフェールオーバーより長くなります。トレードオフとして、AG をフェールオーバーするときに、SQL Server エージェントジョブを有効にするなど、データベースを使用できるようにするために追加タスクが必要になる場合があります。

AG と同様に、FCI は基になるクラスターのどのノードによってホストされているかを抽象化します。 FCI は常に同じ名前を保持します。アプリケーションとエンドユーザーはノードに接続せず、FCI に割り当てられている一意の名前が使用されます。 FCI は、プライマリまたはセカンダリのいずれかのレプリカをホストしているインスタンスの 1 つとして、AG に参加できます。

次のリストは、Windows Server と Linux 上の FCI でのいくつかの違いを示しています。

Windows Server では、FCI はインストールプロセスの一部です。 Linux では、FCI は SQL Server のインストール後に構成されます。
Linux は、ホストあたり 1 つの SQL Server のインストールしかサポートしないため、すべての FCI が既定のインスタンスになります。 Windows Server は、WSFC あたり最大 25 の FCI をサポートします。
Linux で FCI によって使用される共通名は DNS で定義され、FCI 用に作成されたリソースと同じ名前である必要があります。

ログ配布

復旧ポイントの目標と復旧時間の目標により柔軟性がある場合、またはデータベースが非常にミッションクリティカルであると見なされていない場合は、ログ配布が SQL Server におけるもう 1 つの実証済みの可用性機能となります。 SQL Server のネイティブバックアップに基づき、ログ配布のプロセスによってトランザクションログバックアップが自動的に生成され、ウォームスタンバイ状態であることが判明している 1 つ以上のインスタンスにコピーされ、そのスタンバイにトランザクションログバックアップが自動的に適用されます。ログ配布は、SQL Server エージェントジョブを使用して、バックアップ、コピー、およびトランザクションログバックアップの適用のプロセスを自動化します。

ログ配布の図。

ほぼ間違いなく、一部の容量でログ配布を使用する最大の利点は、ヒューマンエラーに対処することです。トランザクションログの適用が遅れる場合があります。そのため、他のユーザーが WHERE 句なしで UPDATE のようなものを発行すると、スタンバイに変更されずに、プライマリシステムの修復中にスタンバイに切り替えることができます。ログ配布は構成が容易ですが、プライマリからウォームスタンバイ状態に切り替える (ロール切り替えと呼ばれます) のは常に手動です。ロール切り替えは Transact-SQL によって開始され、AG と同様に、トランザクションログにキャプチャされないすべてのオブジェクトを手動で同期する必要があります。 1 つの AG には複数のデータベースを含めることができるのに対し、ログ配布はデータベースごとに構成する必要があります。

AG や FCI とは異なり、ログ配布にはロール切り替えの抽象化がなく、アプリケーションで処理できる必要があります。 DNS エイリアス (CNAME) などの手法も使用できますが、切り替え後に DNS の更新に時間がかかるなど、良い点と悪い点があります。