このページは Cloud Translation API によって翻訳されました。

マルチリージョンでの障害復旧を目的とした Microsoft SQL Server のデプロイ

このチュートリアルでは、障害復旧（DR）ソリューションとして 2 つの Google Cloud リージョンで Microsoft SQL Server データベースシステムをデプロイして管理する方法について説明します。また、障害が発生したデータベースインスタンスから正常に稼働しているインスタンスにフェイルオーバーする方法について説明します。このドキュメントにおいては、障害とはプライマリデータベースで障害が発生する、可用性が失われるイベントを意味します。

プライマリデータベースは、配置されているリージョンに障害が発生したり、アクセスできなくなったりした場合に障害となる可能性があります。リージョンが利用可能で正常に動作している場合でも、システムエラーが原因でプライマリデータベースに障害が発生することがあります。この場合、障害復旧はクライアントが処理を継続するために、セカンダリデータベースを利用できるようにするプロセスです。

このチュートリアルは、データベースアーキテクト、管理者、エンジニアを対象としています。

目標

Microsoft SQL Server の AlwaysOn 可用性グループを使用して、Google Cloud にマルチリージョン障害復旧環境をデプロイします。
障害イベントをシミュレートし、完全な障害復旧プロセスを実行して障害復旧構成を検証します。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

このチュートリアルでは、Google Cloud プロジェクトが必要です。新しいプロジェクトを作成することも、すでに作成済みのプロジェクトを選択することもできます。

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

プロジェクトセレクタに移動
Google Cloud プロジェクトで課金が有効になっていることを確認します。
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

障害復旧について

Google Cloud の障害復旧（DR）は、特にリージョンで障害が発生した場合やアクセスできなくなった場合に、処理の継続性を提供することが目的です。データベース管理システムなどのシステムの場合、少なくとも 2 つのリージョンにシステムをデプロイして DR を実装します。この設定では、1 つのリージョンが使用不可能になってもシステムは引き続き動作します。

データベースシステムの障害復旧

プライマリデータベースインスタンスで障害発生時にセカンダリデータベースに切り替えるプロセスをデータベースの障害復旧（データベース DR）といいます。このコンセプトの詳細については、Microsoft SQL Server の障害復旧をご覧ください。セカンダリデータベースの状態は、プライマリデータベースが使用不能になった時点か、プライマリデータベースの最近のトランザクションの一部が欠落している時点において、プライマリデータベースの状態と一致することが理想的です。

障害復旧アーキテクチャ

Microsoft SQL Server について、次の図で、データベース DR をサポートする最小限のアーキテクチャを示しています。

プライマリインスタンスとスタンバイインスタンスは、リージョン R1 の 2 つのゾーンにわたっており、セカンダリインスタンスはリージョン R2 に配置されています。

図 1. Microsoft SQL Server を使用した標準障害復旧アーキテクチャ。

このアーキテクチャは次のように機能します。

Microsoft SQL Server の 2 つのインスタンス（プライマリインスタンスとスタンバイインスタンス）は同じリージョン（R1）にありますが、ゾーンは異なります（ゾーン A と B）。R1 の 2 つのインスタンスは、同期 commit モードを使用して状態を調整しています。同期モードは高可用性を実現し、一貫したデータ状態を維持する目的で使用されます。
Microsoft SQL Server の 1 つのインスタンス（セカンダリまたは障害復旧インスタンス）が 2 番目のリージョン（R2）に配置されます。DR を実施する際には、非同期 commit モードを使用して、R2 のセカンダリインスタンスが R1 のプライマリインスタンスと同期します。非同期モードが使用される理由は、そのパフォーマンスにあります（プライマリインスタンスでの commit 処理の速度が低下しません）。

上の図で、アーキテクチャは可用性グループを示しています。可用性グループがリスナーで使用される場合、クライアントが以下によって配信されるとクライアントに同じ接続文字列が提供されます。

プライマリインスタンス
スタンバイインスタンス（ゾーン障害の後）
セカンダリインスタンス（リージョン障害の後、およびセカンダリインスタンスが新しいプライマリインスタンスになった後）

上に示したアーキテクチャのバリアントでは、最初のリージョン（R1）の 2 つのインスタンスを同じゾーンにデプロイします。このアプローチによってパフォーマンスが向上する可能性がありますが、可用性は高くありません。DR プロセスを開始するために、1 つのゾーンの停止が必要になる可能性があります。

基本的な障害復旧プロセス

リージョンが利用できなくなり、プライマリデータベースがフェイルオーバーして別の運用リージョンで処理を再開すると、DR プロセスが開始されます。リージョン障害を軽減し、使用可能なリージョンで実行するプライマリインスタンスを確立するために、DR プロセスは手動または自動で実行されるべき運用ステップを規定します。

基本的なデータベース DR プロセスは、次の手順で構成されます。

プライマリデータベースインスタンスを実行している最初のリージョン（R1）が使用できなくなります。
オペレーションチームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
フェイルオーバーが必要な場合は、2 番目のリージョン（R2）のセカンダリデータベースインスタンスが新しいプライマリインスタンスに設定されます。
クライアントは、新しいプライマリデータベースで処理を再開し、R2 のプライマリインスタンスにアクセスします。

この基本的なプロセスは、稼働中のプライマリデータベースを再度確立しますが、完全なプライマリ DR アーキテクチャを確立しません。このアーキテクチャでは、新しいプライマリには、スタンバイとセカンダリのデータベースインスタンスがあります。

完全な障害復旧プロセス

完全な DR プロセスでは、フェイルオーバー後に完全な DR アーキテクチャを確立するためのステップを追加することで、基本的な DR プロセスを拡張します。次の図は、データベースの完全な DR アーキテクチャを示しています。

完全なデータベース DR アーキテクチャでは、リージョン R2 のセカンダリインスタンスがプライマリになり、新しいセカンダリインスタンスがリージョン R3 に作成されます。

図 2.使用できないプライマリリージョン（R1）での障害復旧。

このデータベースの完全な DR アーキテクチャは、次のように機能します。

プライマリデータベースインスタンスを実行している最初のリージョン（R1）が使用できなくなります。
オペレーションチームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
フェイルオーバーが必要な場合は、2 番目のリージョン（R2）のセカンダリデータベースインスタンスがプライマリインスタンスに設定されます。
別のセカンダリインスタンス（新しいスタンバイインスタンス）が作成され、R2 で起動され、プライマリインスタンスに追加されます。スタンバイインスタンスは、プライマリインスタンスとは異なるゾーンにあります。プライマリデータベースは、高可用性を備えた 2 つのインスタンス（プライマリとスタンバイ）で構成されるようになりました。
3 番目のリージョン（R3）では、新しいセカンダリ（スタンバイ）データベースインスタンスが作成され開始されます。このセカンダリインスタンスは、R2 の新しいプライマリインスタンスに非同期で接続されます。この時点で元の障害復旧アーキテクチャが再作成され、稼働を開始します。

復元したリージョンへのフォールバック

オンラインに復帰した後、最初のリージョン（R1）は新しいセカンダリデータベースをホストできます。R1 の復旧が十分に速ければ、R3（3 番目のリージョン）ではなく、R1 の完全復旧プロセスのステップ 5 を実装できます。この場合 3 番目のリージョンは必要ありません。

次の図は、R1 が時間内に使用可能になった場合のアーキテクチャを示しています。

リージョン R1 が時間内に復旧すると、セカンダリインスタンスがリージョン R1 に作成されます。

図 3.障害が発生したリージョン R1 が再度利用可能になった後の障害復旧。

このアーキテクチャーでのリカバリー手順は、R1 が R3 の代わりにセカンダリインスタンスのロケーションになるという違いを除いて、前に完全な障害復旧プロセスで概説した手順と同じです。

SQL Server のエディションの選択

このチュートリアルは、次のバージョンの Microsoft SQL Server に対応しています。

SQL Server 2016 Enterprise Edition
SQL Server 2017 Enterprise Edition
SQL Server 2019 Enterprise Edition
SQL Server 2022 Enterprise Edition

このチュートリアルでは SQL Server の AlwaysOn 可用性グループ機能を使用します。

高可用性（HA）Microsoft SQL Server プライマリデータベースが必要でなく、単一のデータベースインスタンスがプライマリとして十分である場合は、次のバージョンの SQL Server を使用できます。

SQL Server 2016 Standard Edition
SQL Server 2017 Standard Edition
SQL Server 2019 Standard Edition
SQL Server 2022 Standard Edition

SQL Server の 2016 年、2017 年、2019 年、2022 年のバージョンは、Microsoft SQL Server Management Studio がイメージにインストールされています。別途インストールする必要はありません。ただし本番環境では、Microsoft SQL Server Management Studio の 1 つのインスタンスを、各リージョンの個別の VM にインストールすることをおすすめします。HA 環境を設定する場合は、ゾーンごとに Microsoft SQL Server Management Studio をインストールして、他のゾーンが使用できなくなっても、使用を継続できるようにしてください。

マルチリージョン DR 向けに Microsoft SQL Server を設定する

このセクションでは、Microsoft SQL Server に次のイメージを使用します。

Microsoft SQL Server 2016 Enterprise Edition の場合: sql-ent-2016-win-2016
Microsoft SQL Server 2017 Enterprise Edition の場合: sql-ent-2017-win-2016
Microsoft SQL Server 2019 Enterprise Edition の場合: sql-ent-2019-win-2019
Microsoft SQL Server 2022 Enterprise Edition の場合: sql-ent-2022-win-2022

イメージの完全なリストについては、イメージをご覧ください。

2 インスタンス高可用性クラスタを設定する

SQL Server のマルチリージョンデータベース DR アーキテクチャを設定するには、まず 2 つのインスタンスの高可用性（HA）クラスタを 1 つのリージョンに作成します。一方のインスタンスはプライマリとして機能し、もう一方はセカンダリとして機能します。この手順を行うには、SQL Server AlwaysOn 可用性グループの構成の手順に沿って操作します。このチュートリアルでは、プライマリリージョン（R1 と呼びます）に us-central1 を使用します。始める前に、以下の注意事項を確認してください。

SQL Server AlwaysOn 可用性グループの構成の手順を行った場合、同じリージョン（us-central1）に 2 つの SQL Server インスタンスを作成することになります。プライマリ SQL Server インスタンス（node-1）を us-central1-a にデプロイし、スタンバイインスタンス（node-2）を us-central1-b にデプロイします。
このチュートリアルでは図 4 のアーキテクチャを実装しますが、複数のゾーンでドメインコントローラを設定することをおすすめします。このアプローチにより、HA と DR 対応のデータベースアーキテクチャを確実に設定できます。たとえば、1 つのゾーンでシステム停止が発生しても、そのゾーンは、デプロイされたアーキテクチャでの単一障害点にはなりません。

同期モードのプライマリインスタンスとスタンバイインスタンスが、1 つのリージョン内の別々のゾーンにあり、非同期モードのセカンダリインスタンスが別のリージョンにあります。

図 4.このチュートリアルで実装されている標準的な障害復旧アーキテクチャ。

障害復旧のためにセカンダリインスタンスを追加する

次に、3 つ目の SQL Server インスタンス（node-3 という名前のセカンダリインスタンス）をセットアップし、ネットワークを次のように構成します。

Windows Server フェイルオーバークラスタノード用の専用スクリプトを作成します。このスクリプトは、必要な Windows 機能をインストールし、WSFC と SQL Server 用のファイアウォールルールを作成します。また、データディスクのフォーマットを行い、SQL Server 用のデータフォルダとログフォルダを作成します。

cat << "EOF" > specialize-node.ps1

$ErrorActionPreference = "stop"

# Install required Windows features
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Install-WindowsFeature RSAT-AD-PowerShell

# Open firewall for WSFC
netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997

# Open firewall for SQL Server
netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433

# Open firewall for SQL Server replication
netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022

# Format data disk
Get-Disk |
 Where partitionstyle -eq 'RAW' |
 Initialize-Disk -PartitionStyle MBR -PassThru |
 New-Partition -AssignDriveLetter -UseMaximumSize |
 Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false

# Create data and log folders for SQL Server
md d:\Data
md d:\Logs
EOF

次の変数を初期化します。
```
VPC_NAME=VPC_NAME
SUBNET_NAME=SUBNET_NAME
REGION=us-east1
PD_SIZE=200
MACHINE_TYPE=n2-standard-8
```
ここで
- VPC_NAME: VPC の名前
- SUBNET_NAME: us-east1 リージョンのサブネットの名前

SQL Server インスタンスを作成します。

gcloud compute instances create node-3 \
--zone $REGION-b \
--machine-type $MACHINE_TYPE \
--subnet $SUBNET_NAME \
--image-family sql-ent-2022-win-2022 \
--image-project windows-sql-cloud \
--tags wsfc,wsfc-node \
--boot-disk-size 50 \
--boot-disk-type pd-ssd \
--boot-disk-device-name "node-3" \
--create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
--metadata enable-wsfc=true \
--metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1

新しい SQL Server インスタンスに Windows パスワードを設定します。
1. Google Cloud コンソールで [Compute Engine] ページに移動します。
  
  Compute Engine に移動
2. Compute Engine クラスタ node-3 の [接続] 列で、[Windows パスワードを設定] プルダウンリストを選択します。
3. ユーザー名とパスワードを設定します。後で使用できるようにメモしておいてください。
[RDP] をクリックして、node-3 インスタンスに接続します。
前の手順で設定したユーザー名とパスワードを入力し、[OK] をクリックします。
インスタンスを Windows ドメインに追加します。
1. [スタート] ボタンを右クリックするか Win + X を押して、[Windows PowerShell（管理者）] をクリックします。
2. 特権昇格を確認するプロンプトが表示されたら [はい] をクリックします。
3. コンピュータを Active Directory ドメインに追加して再起動します。
```
Add-Computer -Domain DOMAIN -Restart
```
  DOMAIN は、Active Directory ドメインの DNS 名に置き換えます。
  
  再起動が完了するまで 1 分ほど待ちます。

セカンダリインスタンスをフェイルオーバークラスタに追加する

次に、セカンダリインスタンス（node-3）を Windows フェイルオーバークラスタに追加します。

RDP を使用して node-1 インスタンスまたは node-2 インスタンスに接続し、管理者ユーザーとしてログインします。
管理者ユーザーとして PowerShell ウィンドウを開き、このチュートリアルのクラスタ環境の変数を設定します。
```
$node3 = "node-3"
$nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
```
SQLSRV_CLUSTER は、SQL Server クラスタの名前に置き換えます。
セカンダリインスタンスをクラスタに追加します。
```
Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
```
このコマンドの実行には時間を要する場合があります。プロセスが応答しなくなり、自動的に結果を返さなくなる可能性があるため、場合によっては Enter を押します。
ノードで、AlwaysOn 高可用性機能を有効にします。
```
Enable-SqlAlwaysOn -ServerInstance $node3 -Force
```

これで、ノードがフェイルオーバークラスタの一部になりました。

セカンダリインスタンスを既存の可用性グループに追加する

次に、SQL Server インスタンス（セカンダリインスタンス）とデータベースを可用性グループに追加します。

リモートデスクトップを使用して、node-3 に接続します。ドメインユーザーアカウントでログインします。
SQL Server 構成マネージャーを開きます。
ナビゲーションパネルで [SQL Server Services] を選択します。
サービスのリストで [SQL Server（MSSQLSERVER）] を右クリックし、[プロパティ] を選択します。
[ログオン] でアカウントを変更します。
- アカウント名: DOMAIN\sql_server。DOMAIN は Active Directory ドメインの NetBIOS 名です。
- パスワード: 前に sql_server ドメインアカウントに選択したパスワードを入力します。
[OK] をクリックします。
SQL Server の再起動を求めるプロンプトが表示されたら、[はい] を選択します。
3 つのインスタンスノード（node-1、node-2 または node-3）のいずれかで、Microsoft SQL Server Management Studio を開いてプライマリインスタンス（node-1）に接続します。
1. Object Explorer に移動します。
2. [接続] プルダウンリストを選択します。
3. [データベースエンジン] を選択します。
4. [サーバー名] プルダウンリストから、[node-1] を選択します。クラスタがリストに表示されない場合は、フィールドに入力します。
[新しいクエリ] をクリックします。

注: AlwaysOn 可用性グループの設定に分散ネットワーク名が使用されている場合は、ステップ 9 と 10 は不要です。
次のコマンドをペーストして、ノードに使用するリスナーに IP アドレスを追加し、[実行] をクリックします。
```
ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
```
LOAD_BALANCER_IP_ADDRESS は、us-east1 リージョンのロードバランサの IP アドレスに置き換えます。
オブジェクトエクスプローラで、[AlwaysOn 高可用性] ノードを開いてから、[可用性グループ] ノードを開きます。
bookshelf-ag という名前の可用性グループを右クリックし、[レプリカを追加] を選択します。
[概要] ページで、[AlwaysOn 高可用性] ノードをクリックしてから、[可用性グループ] ノードをクリックします。
[レプリカに接続] ページで、[接続] をクリックして、既存のセカンダリレプリカ node-2 に接続します。
[レプリカの指定] ページで、[レプリカを追加] をクリックし、新しいノード node-3 を追加します。自動フェイルオーバーによって同期コミットが発生するため、[自動フェイルオーバー] は選択しないでください。このような設定はリージョンの境界を超えるため、おすすめしません。
[データ同期の選択] ページで、[Automatic Seeding] を選択します。

リスナーが存在しないため、[検証] ページで警告が生成されますが、無視しても問題ありません。
ウィザードの手順を完了します。

node-1 と node-2 のフェイルオーバーモードは自動的に設定されますが、node-3 では手動での設定が必要です。この違いは、高可用性と障害復旧を区別する 1 つの方法になります。

可用性グループが使用可能になりました。高可用性のために 2 つのノードを構成し、障害復旧用に 3 つ目のノードを構成しました。

障害復旧のシミュレーション

このセクションでは、このチュートリアルによる障害復旧アーキテクチャをテストし、またオプション DR の実装も検討します。

停止をシミュレーションして DR フェイルオーバーを実行する

プライマリリージョンで障害または停止をシミュレーションします。
1. node-1 の Microsoft SQL Server Management Studio で、node-1 に接続します。
2. テーブルを作成します。後の手順でレプリカを追加した後に、このテーブルが存在するかどうかを確認して、レプリカが正常に動作することを検証します。
```
USE bookshelf
GO
CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
GO
```
3. Cloud Shell で、プライマリリージョン（us-central1）にある両方のサーバーをシャットダウンします。
```
gcloud compute instances stop node-2 --zone us-central1-b --quiet
gcloud compute instances stop node-1 --zone us-central1-a --quiet
```
注: 障害を発生させるもう一つの方法としては、node-1 と node-2 を実行している VM を停止する方法があります。このアプローチは、通常のインスタンスシャットダウンではなく、ハード障害をシミュレーションするものです。
node-3 の Microsoft SQL Server Management Studio で、node-3 に接続します。
フェイルオーバーを実行し、可用性モードを同期 commit に設定します。ノードが非同期 commit モードのため、フェイルオーバーの強制が必要です。
```
ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO
```
処理を再開できます。node-3 がプライマリインスタンスになりました。
（省略可）node-3 に新しいテーブルを作成します。レプリカを新しいプライマリと同期した後、このテーブルがレプリカに複製されているかどうかを確認します。
```
USE bookshelf
GO
CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
GO
```

この時点で node-3 がプライマリですが、元のリージョンにフォールバックするか、新しいセカンダリインスタンスとスタンバイインスタンスを設定して、完全な DR アーキテクチャを再作成することをおすすめします。次のセクションでは、これらの選択肢について説明します。

（省略可）トランザクションを完全に複製する DR アーキテクチャを再作成する

このユースケースは、プライマリに障害が発生する前にすべてのトランザクションがプライマリデータベースからセカンダリデータベースに複製される障害に対処します。この理想的なシナリオではデータが失われることはありません。障害が発生した時点で、セカンダリの状態がプライマリと整合しています。

このシナリオでは次の 2 つの方法で完全な DR アーキテクチャを再作成できます。

元のプライマリと元のスタンバイ（使用可能な場合）にフォールバックする。
元のプライマリとスタンバイが利用できない場合に、node-3 に新しいスタンバイとセカンダリを作成する。

アプローチ 1: 元のプライマリとスタンバイにフォールバックする

Cloud Shell で、元の（古い）プライマリとスタンバイを起動します。

gcloud compute instances start node-1 --zone us-central1-a --quiet
gcloud compute instances start node-2 --zone us-central1-b --quiet

Microsoft SQL Server Management Studio で、node-1 と node-2 をセカンダリレプリカとして追加します。

node-3 で、2 つのサーバーを非同期コミットモードで追加します。

USE [master]
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

node-1 で、データベースを再度同期します。

USE [master]
GO
ALTER DATABASE [bookshelf] SET HADR RESUME;
GO

node-2 で、データベースを再度同期します。

USE [master]
GO
ALTER DATABASE [bookshelf] SET HADR RESUME;
GO

node-1 を再度プライマリにします。

node-3 で、node-1 の可用性モードを同期 commit に変更します。インスタンス node-1 が再びプライマリになります。
```
USE [master]
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO
```

node-1 で、node-1 をプライマリに、他の 2 つのノードをセカンダリに変更します。

USE [master]
GO
-- Node 1 becomes primary
ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

-- Node 2 has synchronous commit
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

-- Node 3 has asynchronous commit
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

すべてのコマンドが成功すると、次の図に示すように、node-1 がプライマリになり、他のノードはセカンダリになります。

Object Explorer に可用性グループが表示されています。

アプローチ 2: 新しいプライマリとスタンバイを設定する

元のプライマリインスタンスとスタンバイインスタンスを障害から復元できない場合、復元に時間がかかりすぎる場合、リージョンにアクセスできない場合があります。一つの方法は、次の図に示すように、node-3 をプライマリのままにして、新しいスタンバイインスタンスと新しいセカンダリインスタンスを作成することです。

スタンバイインスタンスは別のゾーンに作成されますが、リージョンはプライマリと同じです。セカンダリインスタンスは別のリージョンに作成されます。

図 5. 元のプライマリリージョン R1 が使用できない場合の障害復旧。

この実装では、次のことを行う必要があります。

node-3 を us-east1 でプライマリのままにします。
新しいスタンバイインスタンス（node-4）を us-east1 の別のゾーンに追加します。この手順により新しいデプロイが高可用性として確立されます。
別のリージョン（us-west2 など）に新しいセカンダリインスタンス（node-5）を作成します。この手順では障害復旧のために新しいデプロイを設定します。これでデプロイの全体が完了です。データベースアーキテクチャは HA と DR を完全にサポートしています。

（省略可）トランザクションがない場合にフォールバックを実行する

理想的ではない障害としては、プライマリで commit された 1 つ以上のトランザクションが、障害発生時にセカンダリに複製されない場合です（ハード障害とも呼ばれます）。フェイルオーバーでは、複製されていない commit されたトランザクションはすべて失われます。

このシナリオのフェイルオーバーの手順をテストするには、ハード障害を発生させる必要があります。ハード障害を発生させる最も良い方法は次のとおりです。

ネットワークを変更して、プライマリインスタンスとセカンダリインスタンスの間の接続がないようにします。
プライマリを変更する（例: テーブルを追加する、データを挿入する）
前述のフェイルオーバープロセスを順に実行して、セカンダリを新しいプライマリにします。

フェイルオーバープロセスのステップは、理想的なシナリオと同じですが、ネットワーク接続の中断後にプライマリに追加されたテーブルは、セカンダリでは表示されません。

ハード障害に対処する唯一の方法は、可用性グループからレプリカ（node-1 と node-2）を削除して、これらのレプリカを再度同期することです。同期することでセカンダリの状態に変化します。障害発生前に複製されなかったトランザクションは失われます。

node-1 をセカンダリインスタンスとして追加するには、前述した node-3 を追加するのと同じ手順に沿って操作します（フェイルオーバークラスタにセカンダリインスタンスを追加するを参照）。ただし、node-1 ではなく、node-3 がプライマリになっている点が異なります。node-3 のインスタンスを可用性グループに追加するサーバーの名前に置き換える必要があります。同じ VM（node-1 と node-2）を再利用する場合は、サーバーを Windows Server フェイルオーバークラスタに追加する必要はありません。SQL Server インスタンスを可用性グループに再度追加する処理のみを行います。

この時点で node-3 はプライマリ、node-1 と node-2 はセカンダリです。node-1 にフォールバックして、node-2 をスタンバイにし、node-3 をセカンダリにできるようになりました。これでシステムは障害前の状態と同じになりました。

自動フェイルオーバー

セカンダリインスタンスにプライマリとして自動的にフェイルオーバーすると、問題が発生する場合があります。元のプライマリが再び使用可能になった後、一部のクライアントがセカンダリにアクセスして、他のクライアントが復元されたプライマリに書き込みを行うと、スプリットブレインの状況が発生します。この場合、プライマリとセカンダリが並行して更新され、異なる状態となる可能性があります。このような状況を回避するために、このチュートリアルでは手動フェイルオーバーの手順について説明します。手動フェイルオーバーでは、フェイルオーバーをするかどうか（またはそのタイミング）を決定できます。

自動フェイルオーバーを実装する場合は、構成された 1 つのインスタンスのみをプライマリとし、変更可能にする必要があります。スタンバイインスタンスまたはセカンダリインスタンスでは、クライアントには書き込み権限を提供しないでください（状態複製用のプライマリを除く）。また、短期間にフェイルオーバーが連続して繰り返されることは回避する必要があります。たとえば、5 分ごとにフェイルオーバーすることは、信頼できる障害復旧戦略とは言えません。自動フェイルオーバープロセスの場合は、このような問題のある状況に対する予防策に組み込むことができます。また、必要に応じてデータベース管理者による支援を得て、複雑な判断を下せるようにすることもできます。

代替デプロイアーキテクチャ

このチュートリアルでは、次の図に示すように、フェイルオーバーにおいてプライマリインスタンスとなるセカンダリインスタンスを有する障害復旧アーキテクチャを設定します。

図 6. Microsoft SQL Server を使用した標準障害復旧アーキテクチャ。

つまりフェイルオーバーの場合、フォールバックが可能になるまで、またはスタンバイ（HA の場合）とセカンダリ（DR の場合）を構成するまで、結果のデプロイには単一のインスタンスが存在します。

別のデプロイアーキテクチャでは、2 つのセカンダリインスタンスを構成します。どちらのインスタンスもプライマリのレプリカです。フェイルオーバーが発生した場合、セカンダリのうちの 1 つをスタンバイとして構成できます。次の図は、フェイルオーバーの前後のデプロイアーキテクチャを示しています。

2 つのセカンダリインスタンスはリージョン R2 の別々のゾーンに配置されています。

図 7. 2 つのセカンダリインスタンスを持つ標準的な障害復旧アーキテクチャ。

フェイルオーバーの後、リージョン R2 のセカンダリインスタンスの 1 つがスタンバイインスタンスになります。

図 8.フェイルオーバー後の 2 つのセカンダリインスタンスを持つ標準的な障害復旧アーキテクチャ。

2 つのセカンダリのいずれかをスタンバイ（図 8）にする必要がありますが、新しいスタンバイをゼロから作成して構成するよりもはるかに高速です。

2 つのセカンダリインスタンスを使用するこのアーキテクチャに似たセットアップで DR に対応することもできます。2 番目のリージョンに 2 つのセカンダリを用意する（図 7）だけでなく、3 番目のリージョンにさらに 2 つのセカンダリをデプロイできます。この設定により、プライマリリージョンでの障害発生後に適用する、HA と DR に対応したデプロイアーキテクチャを効率的に作成できます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにする手順は次のとおりです。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。