Linux で高可用性を実現するために SQL Server の Always On 可用性グループを構成する

[アーティクル]
10/30/2023

適用対象: 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 ディストリビューションによって異なります。ディストリビューション固有の手順については、以下のリンクをご覧ください。
- RHEL
- SUSE
- Ubuntu
重要

運用環境では、高可用性を実現するためにフェンシングエージェントが必要です。この記事の例では、フェンスエージェントは使用しません。これらはテストと検証専用です。

Pacemaker クラスターは、フェンスを使用してクラスターを既知の状態に戻します。フェンスを構成する方法は、ディストリビューションと環境によって異なります。現在、フェンシングは一部のクラウド環境では利用できません。詳細については、RHEL 高可用性クラスターのサポートポリシー (仮想化プラットフォーム) に関するページをご覧ください。

SLES については、SUSE Linux Enterprise High Availability Extension に関するページをご覧ください。
AG をリソースとしてクラスターに追加します。

AG をリソースとしてクラスターに追加する方法は、Linux ディストリビューションによって異なります。ディストリビューション固有の手順については、以下のリンクをご覧ください。
- RHEL
- SLES
- Ubuntu

複数のネットワークインターフェイス (NIC) に関する考慮事項

複数の NIC を持つサーバーの可用性グループを設定する方法については、次の関連するセクションを参照してください。

前提条件

可用性グループを作成する前に、以下のことを行う必要があります。

可用性レプリカをホストするすべてのサーバーが通信できるように環境を設定します。
SQL Server をインストールします。

Linux でクラスターで管理するには、クラスターリソースとして追加する前に可用性グループを作成する必要があります。このドキュメントでは、可用性グループを作成する例を示します。

各ホストのコンピューター名を更新します。

各 SQL Server インスタンス名には次の条件があります。
- 15 文字以下。
- ネットワーク内で一意。
コンピューター名を設定するには、/etc/hostname を編集します。次のスクリプトを使うと、vi で /etc/hostname を編集できます。
```
sudo vi /etc/hostname
```
hosts ファイルを構成する。

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 セッションの詳細については、「可用性グループの拡張イベントを構成する」を参照してください。

証明書を作成する

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 エディションを使用する場合、ROLE に有効な値は WITNESS のみです。 SQL Server Express エディションで次のスクリプトを実行します。

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 (14.x) では、データベースミラーリングエンドポイントでサポートされる唯一の認証方法は 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 つの同期レプリカを使って可用性グループを作成する
2 つの同期レプリカと 1 つの構成レプリカを使用して可用性グループを作成する
2 つの同期レプリカを使って可用性グループを作成する

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 (T-SQL) スクリプトを実行し、db1 という名前のデータベースを作成してバックアップします。

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';

プライマリ SQL Server レプリカで、次の T-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;
GO

重要

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 がクラスターリソースの場合、現在のリリースには、非同期レプリカへのデータ損失を伴う強制フェールオーバーが機能しないという既知の問題があります。これは今後のリリースで修正される予定です。同期レプリカへの手動または自動フェールオーバーは成功します。

次の方法で共有

Linux で高可用性を実現するために SQL Server の Always On 可用性グループを構成する

ロードマップ

複数のネットワークインターフェイス (NIC) に関する考慮事項

前提条件

SQL Server をインストールする

Always On 可用性グループを有効にする

AlwaysOn_health イベントセッションを有効にする

証明書を作成する

セカンダリサーバーで証明書を作成する

すべてのレプリカにデータベースミラーリングエンドポイントを作成する

AG を作成する

3 つの同期レプリカを使って可用性グループを作成する

2 つの同期レプリカと 1 つの構成レプリカを使用して可用性グループを作成する

2 つの同期レプリカを使って可用性グループを作成する

セカンダリレプリカを AG に参加させる

可用性グループにデータベースを追加する

セカンダリサーバーにデータベースが作成されたことを確認する

解説

フィードバック

その他のリソース

次の方法で共有

Linux で高可用性を実現するために SQL Server の Always On 可用性グループを構成する

ロードマップ

複数のネットワーク インターフェイス (NIC) に関する考慮事項

前提条件

SQL Server をインストールする

Always On 可用性グループを有効にする

AlwaysOn_health イベント セッションを有効にする

証明書を作成する

セカンダリ サーバーで証明書を作成する

すべてのレプリカにデータベース ミラーリング エンドポイントを作成する

AG を作成する

3 つの同期レプリカを使って可用性グループを作成する

2 つの同期レプリカと 1 つの構成レプリカを使用して可用性グループを作成する

2 つの同期レプリカを使って可用性グループを作成する

セカンダリ レプリカを AG に参加させる

可用性グループにデータベースを追加する

セカンダリ サーバーにデータベースが作成されたことを確認する

解説

関連するコンテンツ

フィードバック

その他のリソース

複数のネットワークインターフェイス (NIC) に関する考慮事項

AlwaysOn_health イベントセッションを有効にする

セカンダリサーバーで証明書を作成する

すべてのレプリカにデータベースミラーリングエンドポイントを作成する

セカンダリレプリカを AG に参加させる

セカンダリサーバーにデータベースが作成されたことを確認する