Linux で高可用性を実現するために SQL Server の Always On 可用性グループを構成する
適用対象:
SQL Server - Linux
この記事では、Linux 上で、高可用性を実現するために SQL Server の Always On 可用性グループ (AG) を作成する方法について説明します。 AG には 2 種類の構成が存在します。 "高可用性" の構成では、クラスター マネージャーを使ってビジネス継続性を提供します。 この構成には、読み取りスケールのレプリカを含めることもできます。 このドキュメントでは、高可用性のための AG を作成する方法について説明します。
"読み取りスケール" のために、クラスター マネージャーなしで AG を作成することもできます。 読み取りスケールの AG は、パフォーマンス スケールアウトのための読み取り専用レプリカを提供します。高可用性は提供しません。 読み取りスケールの AG を作成するには、「Linux で読み取りスケールの SQL Server 可用性グループを構成する」をご覧ください。
高可用性とデータ保護が保証される構成のためには、2 つまたは 3 つの同期コミット レプリカが必要です。 3 つの同期レプリカを使う場合は、1 台のサーバーが使用できない場合でも AG が自動的に復旧されます。 詳細については、「可用性グループ構成の高可用性とデータ保護」をご覧ください。
すべてのサーバーは物理または仮想である必要があり、仮想サーバーは同じ仮想化プラットフォーム上にある必要があります。 この要件が生じるのは、フェンス エージェントがプラットフォーム固有であるためです。 ゲスト クラスターのポリシーに関するページをご覧ください。
ロードマップ
高可用性のために Linux サーバー上に AG を作成する手順は、Windows Server フェールオーバー クラスターでの手順とは異なります。 以下に、おおまかな手順を説明します。
SQL Server on Linux のインストール ガイド。
重要
AG 内の 3 台のサーバーはすべて同じプラットフォーム (物理または仮想) 上に配置する必要があります。これは、Linux の高可用性ではサーバー上のリソースを分離するためにフェンス エージェントが使われるためです。 フェンス エージェントは、各プラットフォームに固有のものです。
AG を作成します。 この手順について、この現在の記事で説明します。
Pacemaker などのクラスター リソース マネージャーを構成します。
クラスター リソース マネージャーを構成する方法は、特定の Linux ディストリビューションによって異なります。 ディストリビューション固有の手順については、以下のリンクをご覧ください。
重要
運用環境では、高可用性を実現するためにフェンシング エージェントが必要です。 この記事の例では、フェンス エージェントは使用しません。 これらはテストと検証専用です。
Pacemaker クラスターは、フェンスを使用してクラスターを既知の状態に戻します。 フェンスを構成する方法は、ディストリビューションと環境によって異なります。 現在、フェンシングは一部のクラウド環境では利用できません。 詳細については、RHEL 高可用性クラスターのサポート ポリシー (仮想化プラットフォーム) に関するページをご覧ください。
SLES については、SUSE Linux Enterprise High Availability Extension に関するページをご覧ください。
AG をリソースとしてクラスターに追加します。
AG をリソースとしてクラスターに追加する方法は、Linux ディストリビューションによって異なります。 ディストリビューション固有の手順については、以下のリンクをご覧ください。
複数のネットワーク インターフェイス (NIC) に関する考慮事項
複数の NIC を持つサーバーの可用性グループを設定する方法については、次の関連するセクションを参照してください。
前提条件
可用性グループを作成する前に、以下のことを行う必要があります。
- 可用性レプリカをホストするすべてのサーバーが通信できるように環境を設定します。
- SQL Server をインストールします。
Note
Linux でクラスターで管理するには、クラスター リソースとして追加する前に可用性グループを作成する必要があります。 このドキュメントでは、可用性グループを作成する例を示します。 クラスターを作成し、可用性グループをクラスターのリソースとして追加するディストリビューション固有の説明については、「次のステップ」の後のリンクをご覧ください。
各ホストのコンピューター名を更新します。
各 SQL Server 名には次の条件があります。
- 15 文字以下。
- ネットワーク内で一意。
コンピューター名を設定するには、
/etc/hostnameを編集します。 次のスクリプトを使うと、vi で/etc/hostnameを編集できます。sudo vi /etc/hostnamehosts ファイルを構成する。
Note
ホスト名が IP アドレスで DNS サーバーに登録されている場合、次の手順を実行する必要はありません。 可用性グループの一部として構成されているすべてのノードが、相互通信できることを確認します。 (そのホスト名を ping した場合、その対応する IP アドレスが返される必要があります)。また、
/etc/hostsファイルに、localhost IP アドレス 127.0.0.1 をノードのホスト名とマップするレコードが含まれないことを確認します。すべてのサーバー上の hosts ファイルには、可用性グループに参加するすべてのサーバーの IP アドレスと名前が含まれています。
次のコマンドは、現在のサーバーの IP アドレスを返します。
sudo ip addr show/etc/hostsを更新します。 次のスクリプトを使うと、vi で/etc/hostsを編集できます。sudo vi /etc/hosts次の例は、
node1の/etc/hostsを示しています。node1、node2、node3に対して追加があります。 このサンプルでは、node1がプライマリ レプリカをホストするサーバーを指し、node2とnode3がセカンダリ レプリカをホストするサーバーを指します。127.0.0.1 localhost localhost4 localhost4.localdomain4 ::1 localhost localhost6 localhost6.localdomain6 10.128.18.12 node1 10.128.16.77 node2 10.128.15.33 node3
SQL Server をインストールする
SQL Server をインストールします。 次のリンクは、SQL Server のさまざまなディストリビューションでのインストール手順です。
Always On 可用性グループを有効にする
SQL Server インスタンスをホストする各ノードで Always On 可用性グループを有効にしてから、mssql-server を再起動します。 次のスクリプトを実行します。
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
AlwaysOn_health イベント セッションを有効にする
オプションで拡張イベント (XE) を有効にすると、可用性グループをトラブルシューティングするとき根本原因の診断に役立ちます。 SQL Server の各インスタンスで次のコマンドを実行します。
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO
この XE セッションの詳細については、「Always On 可用性グループの拡張イベントを構成する」を参照してください。
証明書を作成する
Linux 上の SQL Server サービスは、ミラーリングのエンドポイント間の通信を認証するのに証明書を使用します。
次の Transact-SQL スクリプトでは、マスター キーと証明書を作成します。 その後、証明書をバックアップし、秘密キーでファイルをセキュリティ保護します。 強力なパスワードでスクリプトを更新してください。 プライマリ SQL Server インスタンスに接続します。 次の Transact-SQL スクリプトを実行して、証明書を作成します。
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY (
FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
);
この時点で、プライマリ SQL Server レプリカの /var/opt/mssql/data/dbm_certificate.cer には証明書が、var/opt/mssql/data/dbm_certificate.pvk には秘密キーが作成されています。 これら 2 つのファイルを、可用性レプリカをホストするすべてのサーバー上の同じ場所にコピーします。 mssql ユーザーを使うか、またはこれらのファイルへのアクセス許可を mssql ユーザーに付与します。
たとえば、ソース サーバーでは、次のコマンドでファイルがターゲット コンピューターにコピーされます。 **<node2>** の値を、レプリカをホストする SQL Server インスタンスの名前に置き換えます。
cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/
各ターゲット サーバーで証明書にアクセスするアクセス許可を mssql ユーザーに付与します。
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
セカンダリ サーバーで証明書を作成する
次の Transact-SQL スクリプトでは、プライマリ SQL Server レプリカで作成したバックアップからマスター キーと証明書を作成します。 強力なパスワードでスクリプトを更新してください。 暗号化解除パスワードは、前の手順で .pvk ファイルの作成に使ったものと同じパスワードです。 すべてのセカンダリ サーバーで次のスクリプトを実行し、証明書を作成します。
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY (
FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
);
すべてのレプリカにデータベース ミラーリング エンドポイントを作成する
データベース ミラーリング エンドポイントでは、伝送制御プロトコル (TCP) を使用して、データベース ミラーリング セッションに参加するサーバー インスタンス間、または可用性レプリカをホストするサーバー インスタンス間でメッセージを送受信します。 データベース ミラーリング エンドポイントでは、一意な TCP ポート番号でリッスンします。
次の Transact-SQL スクリプトでは、可用性グループに対して Hadr_endpoint という名前のリスニング エンドポイントを作成します。 エンドポイントが起動され、作成した証明書に接続許可が付与されます。 スクリプトを実行する前に、**< ... >** の間の値を置き換えます。 必要に応じて、IP アドレス LISTENER_IP = (0.0.0.0) を含めることができます。 リスナー IP アドレスは、IPv4 アドレスである必要があります。 0.0.0.0 を使用することもできます。
すべての SQL Server インスタンスで、ご利用の環境に合わせて次の Transact-SQL スクリプトを更新します。
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = **<5022>**)
FOR DATABASE_MIRRORING (
ROLE = ALL,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
Note
構成専用のレプリカのホストに 1 つのノードで SQL Server Express Edition を使用する場合、ROLE に有効な値は WITNESS のみです。 SQL Server Express Edition で次のスクリプトを実行します。
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = **<5022>**)
FOR DATABASE_MIRRORING (
ROLE = WITNESS,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
ファイアウォールの TCP ポートをリスナー ポート用に開く必要があります。
重要
SQL Server 2017 リリースのデータベース ミラーリング エンドポイントでサポートされる唯一の認証方法は CERTIFICATE です。 WINDOWS オプションは今後のリリースで有効になる予定です。
詳細については、「データベース ミラーリング エンドポイント (SQL Server)」を参照してください。
AG を作成する
このセクションの例では、Transact-SQL を使って可用性グループを作成する方法について説明します。 SQL Server Management Studio の可用性グループ ウィザードを使うこともできます。 ウィザードを使用して AG を作成した場合、AG にレプリカを参加させるとエラーが返されます。 これを修正するには、すべてのレプリカの AG のペースメーカーに ALTER、CONTROL、および VIEW DEFINITIONS を付与します。 プライマリ レプリカにアクセス許可を付与したら、ウィザードを使って AG にノードを参加させます。ただし、HA を正常に機能させるために、すべてのレプリカに対して権限を付与します。
自動フェールオーバーを確実に行う高可用性を構成する場合、AG には少なくとも 3 つのレプリカが必要です。 次のいずれかの構成で高可用性をサポートできます。
詳細については、「可用性グループ構成の高可用性とデータ保護」をご覧ください。
Note
可用性グループには、追加の同期または非同期レプリカを含めることができます。
Linux で高可用性のための AG を作成します。 CLUSTER_TYPE = EXTERNAL を指定した CREATE AVAILABILITY GROUP を使います。
可用性グループ:
CLUSTER_TYPE = EXTERNAL外部クラスター エンティティにより AG が管理されることを指定します。 Pacemaker は外部クラスター エンティティの例です。 AG のクラスターの種類が外部である場合は、
プライマリおよびセカンダリ レプリカを
FAILOVER_MODE = EXTERNALに設定します。レプリカが外部クラスター マネージャー (Pacemaker など) と連携することを指定します。
以下の Transact-SQL スクリプトでは、ag1 という名前の高可用性の AG が作成されます。 このスクリプトでは、SEEDING_MODE = AUTOMATIC で AG レプリカが構成されます。 この設定により、各セカンダリ サーバー上に SQL Server によってデータベースが自動作成されます。 ご利用の環境に合わせて次のスクリプトを変更してください。 <node1>、<node2>、または <node3> の値を、レプリカをホストする SQL Server インスタンスの名前に置き換えます。 <5022> を、データ ミラーリング エンドポイント用に設定したポートに置き換えます。 AG を作成するには、プライマリ レプリカをホストしている SQL Server インスタンス上で次の Transact-SQL を実行します。
重要
SQL Server リソース エージェントの現在の実装では、ノード名はインスタンスの ServerName プロパティと一致している必要があります。 たとえば、ノード名が node1 である場合は、SQL Server インスタンスで SERVERPROPERTY('ServerName') が node1 を返すことを確認します。 不一致がある場合、Pacemaker リソースの作成後に、レプリカが解決中の状態になります。
この規則が重要になるシナリオとしては、完全修飾ドメイン名を使用する場合があります。 たとえば、クラスターのセットアップ時にノード名として node1.yourdomain.com を使用する場合、SERVERPROPERTY('ServerName') が node1 だけでなく node1.yourdomain.com も返すことを確認してください。 この問題に対する可能な回避策としては、次の方法があります。
- ホスト名を FQDN に変更し、
sp_dropserverおよびsp_addserverストアド プロシージャを使用して SQL Server のメタデータが変更と一致するようにします。 pcs cluster authコマンドのaddrオプションを使って、ノード名を SERVERPROPERTY('ServerName') の値と一致させ、ノード アドレスとして静的 IP を使用します。
次のスクリプトのいずれか 1 つのみを実行します。
3 つの同期レプリカを使って可用性グループを作成する
3 つの同期レプリカを使って AG を作成する:
CREATE AVAILABILITY GROUP [ag1]
WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'<node1>'
WITH (
ENDPOINT_URL = N'tcp://<node1>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node2>'
WITH (
ENDPOINT_URL = N'tcp://<node2>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node3>'
WITH(
ENDPOINT_URL = N'tcp://<node3>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
重要
上記のスクリプトを実行して 3 つの同期レプリカを持つ AG を作成した後は、以下のスクリプトは実行しないでください。
2 つの同期レプリカと 1 つの構成レプリカを使用して可用性グループを作成する
2 つの同期レプリカと 1 つの構成レプリカを使って AG を作成する:
重要
このアーキテクチャでは、任意のエディションの SQL Server を使って 3 番目のレプリカをホストすることができます。 たとえば、SQL Server Express Edition 上で 3 番目のレプリカをホストできます。 Express Edition の場合、有効なエンドポイントの種類は WITNESS のみです。
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'<node1>' WITH (
ENDPOINT_URL = N'tcp://<node1>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node2>' WITH (
ENDPOINT_URL = N'tcp://<node2>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node3>' WITH (
ENDPOINT_URL = N'tcp://<node3>:<5022>',
AVAILABILITY_MODE = CONFIGURATION_ONLY
);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
2 つの同期レプリカを使って可用性グループを作成する
2 つの同期レプリカを使って AG を作成する
同期可用性モードの 2 つのレプリカを含めます。 たとえば、次のスクリプトでは、ag1 という名前の AG が作成されます。 node1 および node2 では、自動シード処理と自動フェールオーバーを備えた、同期モードのレプリカがホストされます。
重要
2 つの同期レプリカを含む AG を作成する場合は、次のスクリプトだけを実行してください。 上記のスクリプトのいずれかを実行している場合は、以下のスクリプトを実行しないでください。
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'node1' WITH (
ENDPOINT_URL = N'tcp://node1:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'node2' WITH (
ENDPOINT_URL = N'tcp://node2:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
SQL Server Management Studio または PowerShell を使って、CLUSTER_TYPE=EXTERNAL で AG を構成することもできます。
セカンダリ レプリカを AG に参加させる
Pacemaker のユーザーは、すべてのレプリカ上の可用性グループに対して ALTER、CONTROL、VIEW DEFINITION のアクセス許可を持っている必要があります。 アクセス許可を付与するには、プライマ リレプリカと各セカンダリ レプリカ上に可用性グループが作成された後、それらが可用性グループに追加された直後に、次の Transact-SQL スクリプトを実行します。 このスクリプトを実行する前に、<pacemakerLogin> を Pacemaker のユーザー アカウントに置き換えます。 Pacemaker のログインがない場合、Pacemaker の SQL サーバー ログインを作成してください。
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>
次の Transact-SQL スクリプトを実行すると、ag1 という名前の AG に SQL Server インスタンスを参加させることができます。 ご利用の環境に合わせてスクリプトを変更してください。 セカンダリ レプリカをホストしている各 SQL Server インスタンス上で、次の Transact-SQL を実行して AG に参加させます。
ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
可用性グループにデータベースを追加する
可用性グループに追加するデータベースが、完全復旧モデルであり、有効なログ バックアップがあることを確認します。 テスト データベースまたは新しく作成されたデータベースの場合は、データベース バックアップを実行します。 プライマリ SQL Server で、次の Transact-SQL スクリプトを実行し、db1 という名前のデータベースを作成してバックアップします。
CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';
プライマリ SQL Server レプリカで、次の Transact-SQL スクリプトを実行して、db1 という名前のデータベースを ag1 という名前の可用性グループに追加します。
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];
セカンダリ サーバーにデータベースが作成されたことを確認する
各セカンダリ SQL Server レプリカで次のクエリを実行して、db1 データベースが作成されて同期されているかどうかを確認します。
SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;
重要
AG を作成したら、高可用性のために Pacemaker のようなクラスター テクノロジとの統合を構成する必要があります。 AG を使った読み取りスケール構成の場合 (SQL Server 2017 (14.x) 以降)、クラスターの設定は必要ありません。
このドキュメントに記載されている手順に従った場合は、まだクラスター化されていない AG ができます。 次の手順は、クラスターを追加することです。 この構成は、読み取りスケール/負荷分散のシナリオに対しては有効ですが、高可用性の場合は完全ではありません。 高可用性を実現するには、AG をクラスター リソースとして追加する必要があります。 手順については、関連した内容を参照してください。
解説
重要
クラスターを構成し、AG をクラスター リソースとして追加した後は、Transact-SQL を使って AG リソースをフェールオーバーすることはできません。 Linux 上の SQL Server クラスター リソースは、Windows Server フェールオーバー クラスター (WSFC) ほど、オペレーティング システムと緊密に結合されていません。 SQL Server サービスでは、クラスターの存在は認識されません。 すべてのオーケストレーションは、クラスター管理ツールを使用して実行されます。 RHEL または Ubuntu では、pcs を使います。 SLES では crm を使います。
重要
AG がクラスター リソースの場合、現在のリリースには、非同期レプリカへのデータ損失を伴う強制フェールオーバーが機能しないという既知の問題があります。 これは今後のリリースで修正される予定です。 同期レプリカへの手動または自動フェールオーバーは成功します。
関連するコンテンツ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示