SQL Server on Linux の可用性グループを作成および構成する

[アーティクル]
12/28/2023

適用対象:SQL Server - Linux

このチュートリアルでは、SQL Server on Linux の可用性グループ (AG) を作成および構成する方法について説明します。 SQL Server 2016 (13.x) on Windows 以前とは異なり、基になる Pacemaker クラスターを最初に作成してもしなくても AG を有効にできます。必要な場合でも、クラスターとの統合は後まで行われません。

チュートリアルには次のタスクが含まれます。

可用性グループを有効にします。
可用性グループのエンドポイントと証明書を作成します。
SQL Server Management Studio (SSMS) または Transact-SQL を使用して可用性グループを作成します。
Pacemaker の SQL Server ログインとアクセス許可を作成します。
Pacemaker クラスターに可用性グループのリソースを作成します (外部タイプのみ)。

前提条件

Pacemaker 高可用性クラスターを「SQL Server on Linux の Pacemaker クラスターをデプロイする」の説明に従ってデプロイします。

可用性グループ機能を有効にする

Windows とは異なり、PowerShell または SQL Server Configuration Manager を使用して可用性グループ (AG) 機能を有効にすることはできません。 Linux では、mssql-conf を使用して機能を有効にする必要があります。可用性グループの機能を有効にするには、mssql-conf ユーティリティを使用する方法と、手動で mssql.conf ファイルを編集する方法の 2 つがあります。

重要

SQL Server Express の場合でも、AG 機能を構成専用レプリカに対して有効にする必要があります。

mssql-conf ユーティリティを使用する

プロンプトで次のコマンドを発行します。

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1

mssql ファイルを編集する

/var/opt/mssql フォルダーにある mssql.conf ファイルを変更して、次の行を追加することもできます。

[hadr]

hadr.hadrenabled = 1

SQL Server を再起動する

Windows の場合と同様に、可用性グループを有効にした後で、次のコマンドを使用して、SQL Server を再起動する必要があります。

sudo systemctl restart mssql-server

可用性グループのエンドポイントと証明書を作成する

可用性グループは通信に TCP エンドポイントを使用します。 Linux では、AG のエンドポイントがサポートされるのは、認証に証明書が使用される場合のみです。 1 つのインスタンスの証明書を、他のすべてのインスタンス (同じ AG にレプリカとして参加する) で復元する必要があります。証明書のプロセスは構成専用レプリカでも必要です。

エンドポイントの作成と証明書の復元は、Transact-SQL を使用してのみ実行できます。 SQL Server によって生成されていない証明書も使用できます。また、証明書を管理したり有効期限が切れた証明書を置き換えるプロセスも必要です。

重要

SQL Server Management Studio ウィザードを使用して AG を作成する予定の場合でも、Linux で Transact-SQL を使用して証明書を作成および復元する必要があります。

さまざまなコマンドで使用できるオプション (追加のセキュリティなど) の完全な構文については、次を参照してください。

Note

可用性グループを作成する場合でも、エンドポイントの種類として FOR DATABASE_MIRRORING を使用します。特徴の一部が、現在非推奨となっているこの機能と共通しているためです。

この例では、3 ノード構成の証明書を作成します。インスタンス名は、LinAGN1、LinAGN2、および LinAGN3 です。

LinAGN1 で次のスクリプトを実行して、マスターキー、証明書、およびエンドポイントを作成し、証明書をバックアップします。この例では、標準の TCP ポート 5022 がエンドポイントに使用されています。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
GO

CREATE CERTIFICATE LinAGN1_Cert
    WITH SUBJECT = 'LinAGN1 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN1_Cert TO FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE ENDPOINT AGEP STATE = STARTED AS TCP (
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING(AUTHENTICATION = CERTIFICATE LinAGN1_Cert, ROLE = ALL);
GO

LinAGN2 で同じ操作を行います。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
GO

CREATE CERTIFICATE LinAGN2_Cert
WITH SUBJECT = 'LinAGN2 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN2_Cert
TO FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP (
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL)
FOR DATABASE_MIRRORING (
    AUTHENTICATION = CERTIFICATE LinAGN2_Cert,
    ROLE = ALL);
GO

最後に、LinAGN3 で同じ手順を実行します。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
GO

CREATE CERTIFICATE LinAGN3_Cert
    WITH SUBJECT = 'LinAGN3 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN3_Cert TO FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

CREATE ENDPOINT AGEP STATE = STARTED AS TCP (
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING(AUTHENTICATION = CERTIFICATE LinAGN3_Cert, ROLE = ALL);
GO

scp または別のユーティリティを使用して、証明書のバックアップを AG の一部となる各ノードにコピーします。

この例の場合は次のとおりです。
- LinAGN1_Cert.cer を LinAGN2 と LinAGN3 にコピーします。
- LinAGN2_Cert.cer を LinAGN1 と LinAGN3 にコピーします。
- LinAGN3_Cert.cer を LinAGN1 と LinAGN2 にコピーします。
所有権と、コピーした証明書ファイルに関連付けられているグループを mssql に変更します。
```
sudo chown mssql:mssql <CertFileName>
```

LinAGN2 と LinAGN3 に関連付けられたインスタンスレベルのログインとユーザーを LinAGN1 上に作成します。

CREATE LOGIN LinAGN2_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN2_User FOR LOGIN LinAGN2_Login;
GO

CREATE LOGIN LinAGN3_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN3_User FOR LOGIN LinAGN3_Login;
GO

LinAGN1 で LinAGN2_Cert と LinAGN3_Cert を復元します。他のレプリカの証明書があることが、AG の通信とセキュリティの重要な側面です。

CREATE CERTIFICATE LinAGN2_Cert AUTHORIZATION LinAGN2_User
FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert AUTHORIZATION LinAGN3_User
FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

LinAG2 と LinAGN3 に関連付けられたログインに、LinAGN1 のエンドポイントに接続するアクセス許可を付与します。
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO
```

LinAGN1 と LinAGN3 に関連付けられたインスタンスレベルのログインとユーザーを LinAGN2 上に作成します。

CREATE LOGIN LinAGN1_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN1_User FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN3_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN3_User FOR LOGIN LinAGN3_Login;
GO

LinAGN2 で LinAGN1_Cert と LinAGN3_Cert を復元します。

CREATE CERTIFICATE LinAGN1_Cert
AUTHORIZATION LinAGN1_User
FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert
AUTHORIZATION LinAGN3_User
FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

LinAG1 と LinAGN3 に関連付けられたログインに、LinAGN2 のエンドポイントに接続するアクセス許可を付与します。
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO
```

LinAGN1 と LinAGN2 に関連付けられたインスタンスレベルのログインとユーザーを LinAGN3 上に作成します。

CREATE LOGIN LinAGN1_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN1_User FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN2_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN2_User FOR LOGIN LinAGN2_Login;
GO

LinAGN3 で LinAGN1_Cert と LinAGN2_Cert を復元します。

CREATE CERTIFICATE LinAGN1_Cert
AUTHORIZATION LinAGN1_User
FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN2_Cert
AUTHORIZATION LinAGN2_User
FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

LinAG1 と LinAGN2 に関連付けられたログインに、LinAGN3 のエンドポイントに接続するアクセス許可を付与します。
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO
```

可用性グループを作成する

このセクションでは、SQL Server Management Studio (SSMS) または Transact-SQL を使用して SQL Server の可用性グループを作成する方法を説明します。

SQL Server Management Studio を使用します

このセクションでは、新しい可用性グループウィザードを使用して、SSMS を使用する外部タイプのクラスターの AG を作成する方法を説明します。

SSMS で、[Always On 高可用性] を展開し、[可用性グループ] を右クリックし、[新しい可用性グループウィザード] を選びます。
[はじめに] ダイアログで [次へ] を選びます。
[可用性グループオプションの指定] ダイアログに、可用性グループの名前を入力し、ドロップダウンでクラスターのタイプとして [EXTERNAL] または [NONE] を選択します。 Pacemaker をデプロイする予定がある場合は [外部] を使用する必要があります。 [なし] は、読み取りスケールアウトなどの特殊なシナリオを対象としています。[データベースレベルの正常性検出] のオプションの選択は省略可能です。このオプションについて詳しくは、「可用性グループのデータベースレベルの正常性検出フェールオーバーオプション」をご覧ください。 [次へ] を選択します。
[データベースの選択] ダイアログで、AG に参加するデータベースを選択します。データベースを AG に追加するには、その前にデータベースごとに完全バックアップが必要です。 [次へ] を選択します。
[レプリカの指定] ダイアログで [レプリカの追加] を選びます。
[サーバーに接続] ダイアログで、セカンダリレプリカにする SQL Server の Linux インスタンスの名前と、接続するための資格情報を入力します。 [接続] を選択します。
前の 2 つの手順を、構成専用レプリカまたは別のセカンダリレプリカを格納するインスタンスに対して繰り返します。
これで、3 つのインスタンスすべてが [レプリカの指定] ダイアログに表示されます。実際にセカンダリにするセカンダリレプリカでクラスタータイプ [外部] を使用している場合は、可用性モードがプライマリレプリカのものと一致し、フェールオーバーモードが [外部] に設定されていることを確認します。構成専用レプリカについては、可用性モードとして [構成のみ] を選択します。

次の例に示す AG には、クラスタータイプが [外部] のものと構成専用レプリカの 2 つのレプリカが含まれます。

次の例に示す AG には、クラスタータイプが [なし] のものと構成専用レプリカの 2 つのレプリカが含まれます。
バックアップの設定を変更する場合は、[バックアップの設定] タブを選びます。AG のバックアップ設定の詳細については、Always On 可用性グループのセカンダリレプリカでのバックアップ構成に関する記事を参照してください。
読み取り可能なセカンダリを使用している場合、または読み取りスケール用にタイプが [なし] のクラスターの AG を作成している場合は、[リスナー] タブを選択してリスナーを作成できます。リスナーは後で追加することもできます。リスナーを作成するには、 [可用性グループリスナーの作成] オプションを選択し、名前と TCP/IP ポート、および静的 DHCP IP アドレスと自動割り当て DHCP IP アドレスのどちらを使用するかを入力します。クラスタータイプが [なし] の AG では、IP は静的にする必要があり、プライマリの IP アドレスを設定する必要があることに注意してください。
読み取り可能なシナリオ用にリスナーが作成されている場合、SSMS 17.3 以降では、ウィザードで読み取り専用ルーティングを作成できます。これは後から SSMS または Transact-SQL を使用して追加することもできます。すぐに読み取り専用ルーティングを追加にするには:
1. [読み取り専用ルーティング] タブを選択します。
2. 読み取り専用レプリカの URL を入力します。これらの URL はエンドポイントに似ていますが、エンドポイントではなくインスタンスのポートを使用する点が異なります。
3. 各 URL を選択し、下部で読み取り可能なレプリカを選択します。複数選択するには、Shift キーを押すか、選んでドラッグします。
[次へ] を選択します。
セカンダリレプリカの初期化方法を選択します。既定では、自動シード処理が使用されます。この場合、AG に参加しているすべてのサーバーで同じパスが必要になります。また、ウィザードでバックアップ、コピー、復元を実行したり (2 番目の方法)、データベースを手動でバックアップし、コピーして、レプリカに復元した場合に、ウィザードを使用して参加させたり (3 番目の方法)、後からデータベースを追加したりすることもできます (最後の方法)。証明書と同様に、手動でバックアップを作成してコピーする場合は、バックアップファイルに対するアクセス許可を他のレプリカに設定する必要があります。 [次へ] を選択します。
[検証] ダイアログで、すべてが成功として返されない場合は調査します。リスナーを作成しない場合など、一部の警告は許容され致命的ではありません。 [次へ] を選択します。
[概要] ダイアログで [完了] を選びます。これで、AG を作成するプロセスが開始されます。
AG の作成が完了したら、[結果] で [閉じる] を選びます。これで、動的管理ビューでレプリカに対する AG を表示することも、SSMS の [Always On 高可用性] フォルダーに AG を表示することもできるようになりました。

Transact-SQL の使用

このセクションでは、Transact-SQL を使用して AG を作成する例を示します。リスナーと読み取り専用ルーティングは、AG の作成後に構成できます。 AG そのものは ALTER AVAILABILITY GROUP を使用して変更できますが、クラスタータイプの変更は SQL Server 2017 (14.x) ではできません。タイプが [外部] のクラスターを含む AG を作成する予定ではなかった場合は、削除して、クラスタータイプ [なし] を含む AG を再作成する必要があります。詳細およびその他のオプションについては、次のリンクを参照してください。

例 A - 構成専用レプリカの 2 つのレプリカ ([外部] クラスタータイプ)

この例では、構成専用レプリカを使用する、2 つのレプリカの AG を作成する方法を示します。

データベースの完全な読み取り/書き込みコピーが含まれている、プライマリレプリカとなるノードで実行します。この例では自動シード処理を使用します。

CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE <DBName>
REPLICA ON N'LinAGN1' WITH (
   ENDPOINT_URL = N' TCP://LinAGN1.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
N'LinAGN2' WITH (
   ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
   SEEDING_MODE = AUTOMATIC),
N'LinAGN3' WITH (
   ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
   AVAILABILITY_MODE = CONFIGURATION_ONLY);
GO

他のレプリカに接続しているクエリウィンドウで次を実行して、レプリカを AG に参加させ、プライマリからセカンダリレプリカへのシード処理を開始します。
```
ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE;
GO
```
構成専用レプリカに接続しているクエリウィンドウで、それを AG に参加させます。
```
ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
```

例 B - 読み取り専用ルーティングの 3 つのレプリカ ([外部] クラスタータイプ)

この例では、3 つの完全なレプリカを示し、最初の AG 作成の一部として読み取り専用ルーティングを構成する方法を説明します。

CREATE AVAILABILITY GROUP [<AGName>] WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE < DBName > REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN2.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:1433')
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:1433')
    ),
    N'LinAGN3' WITH (
        ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN2.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN3.FullyQualified.Name:1433')
    )
    LISTENER '<ListenerName>' (
        WITH IP = ('<IPAddress>', '<SubnetMask>'), Port = 1433
    );
GO

この構成に関する注意事項:

AGName は、可用性グループの名前です。
DBName は、可用性グループで使用されるデータベースの名前です。名前をコンマで区切って指定することもできます。
ListenerName は、基になるサーバー/ノードとは異なる名前です。これは、IPAddress と共に DNS に登録されます。
IPAddress は、ListenerName に関連付けられている IP アドレスです。また、これは一意であり、どのサーバー/ノードとも同じではありません。アプリケーションおよびエンドユーザーは、ListenerName または IPAddress を使用して AG に接続します。
SubnetMask は、IPAddress のサブネットマスクです。 SQL Server 2019 (15.x) 以前のバージョンでは、これは 255.255.255.255 です。 SQL Server 2022 (16.x) 以降のバージョンでは、これは 0.0.0.0 です。

他のレプリカに接続しているクエリウィンドウで次を実行して、レプリカを AG に参加させ、プライマリからセカンダリレプリカへのシード処理を開始します。
```
ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE;
GO
```
3 番目のレプリカに対して手順 2 を繰り返します。

例 C - 読み取り専用ルーティングの 2 つのレプリカ ([なし] クラスタータイプ)

この例では、クラスタータイプ [なし] を使用する 2 レプリカ構成を作成しています。これはフェールオーバーが不要な読み取りスケールのシナリオで使用されます。これによって、実際にプライマリレプリカになるリスナーと、ラウンドロビン機能を使用する読み取り専用ルーティングが作成されます。

データベースの完全な読み取り/書き込みコピーが含まれている、プライマリレプリカとなるノードで実行します。この例では自動シード処理を使用します。

CREATE AVAILABILITY
GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE)
FOR DATABASE <DBName> REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name: <PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(
            ALLOW_CONNECTIONS = READ_WRITE,
            READ_ONLY_ROUTING_LIST = (('LinAGN1.FullyQualified.Name'.'LinAGN2.FullyQualified.Name'))
        ),
        SECONDARY_ROLE(
            ALLOW_CONNECTIONS = ALL,
            READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:<PortOfInstance>'
        )
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
                 ('LinAGN1.FullyQualified.Name',
                    'LinAGN2.FullyQualified.Name')
                 )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfInstance>')
    ),
    LISTENER '<ListenerName>' (WITH IP = (
             '<PrimaryReplicaIPAddress>',
             '<SubnetMask>'),
            Port = <PortOfListener>
    );
GO

ここで:

AGName は、可用性グループの名前です。
DBName は、可用性グループで使用されるデータベースの名前です。名前をコンマで区切って指定することもできます。
PortOfEndpoint は、作成されるエンドポイントで使用されるポート番号です。
PortOfInstance は、SQL Server のインスタンスによって使用されるポート番号です。
ListenerName は、基になるレプリカのいずれとも異なる名前です。実際には使用されません。
PrimaryReplicaIPAddress は、プライマリレプリカの IP アドレスです。
SubnetMask は、IPAddress のサブネットマスクです。 SQL Server 2019 (15.x) 以前のバージョンでは、これは 255.255.255.255 です。 SQL Server 2022 (16.x) 以降のバージョンでは、これは 0.0.0.0 です。

セカンダリレプリカを AG に参加させ、自動シード処理を開始します。

ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = NONE);
GO

ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE;
GO

SQL Server on Linux に基づいている Pacemaker 高可用性クラスターは、SQL Server インスタンスにアクセスする必要があり、可用性グループそのものへのアクセス許可も必要です。これらの手順では、ログインおよび関連するアクセス許可、さらに SQL Server へのログイン方法を Pacemaker に指示するファイルが作成されます。

最初のレプリカに接続しているクエリウィンドウで、次のスクリプトを実行します。

CREATE LOGIN PMLogin WITH PASSWORD ='<StrongPassword>';
GO

GRANT VIEW SERVER STATE TO PMLogin;
GO

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::<AGThatWasCreated> TO PMLogin;
GO

ノード 1 で、コマンドを入力します。
```
sudo emacs /var/opt/mssql/secrets/passwd
```
Emacs エディターが開きます。
エディターに次の 2 行を入力します。
```
PMLogin

<StrongPassword>
```
Ctrl キーを押したまま、X キー、C キーの順に押し、ファイルを終了して保存します。
実行
```
sudo chmod 400 /var/opt/mssql/secrets/passwd
```
ファイルをロックダウンします。
レプリカとして機能する他のサーバーで手順 1 - 5 を繰り返します。

Pacemaker クラスターに可用性グループのリソースを作成する (外部タイプのみ)

クラスタータイプ [外部] を指定したときは、可用性グループが SQL Server に作成された後で、対応するリソースを Pacemaker に作成する必要があります。 AG に関連付けられているリソースには、AG 自体と IP アドレスの 2 つがあります。リスナー機能を使用しない場合、IP アドレスリソースの構成は省略可能ですが推奨されます。

作成した AG リソースは、クローンと呼ばれる特別な種類のリソースです。 AG リソースは基本的に各ノードのコピーを含み、マスターと呼ばれる制御リソースが 1 つあります。マスターは、プライマリレプリカをホストするサーバーに関連付けられています。その他のリソースは、セカンダリレプリカ (標準または構成専用) をホストし、フェールオーバー時にマスターに昇格させることができます。

Note

バイアスフリーなコミュニケーション

この記事には、この文脈で使用した場合に不快感を与えると Microsoft が考える slave (スレーブ、奴隷) という用語の言及が含まれています。これはソフトウェアに現在表示されるものであるため、この記事に出現します。ソフトウェアからこの用語が削除された時点で、この記事から削除します。

Red Hat Enterprise Linux (RHEL) と Ubuntu
SUSE Linux Enterprise Server (SLES)

次の構文を使用して AG リソースを作成します。
```
sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s --master meta notify=true
```
ここで、NameForAGResource は AG のこのクラスターリソースに付ける一意の名前、AGName は作成された AG の名前です。

RHEL 7.7 と Ubuntu 18.04、およびそれ以降のバージョンでは、--master の使用に伴う警告や、sqlag_monitor_0 on ag1 'not configured' (6): call=6, status=complete, exitreason='Resource must be configured with notify=true' のようなエラーが発生する場合があります。この状況を回避するには、次のことを行います。
```
sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s master notify=true
```
リスナー機能に関連付ける AG の IP アドレスリソースを作成します。
```
sudo pcs resource create <NameForIPResource> ocf:heartbeat:IPaddr2 ip=<IPAddress> cidr_netmask=<Netmask>
```
ここで、NameForIPResource は IP リソースの一意の名前、IPAddress はリソースに関連付けられる静的 IP アドレスです。
IP アドレスと AG リソースが同じノードで実行するように、コロケーション制約を構成する必要があります。
```
sudo pcs constraint colocation add <NameForIPResource> <NameForAGResource>-master INFINITY with-rsc-role=Master
```
ここで、NameForIPResource は IP リソースの名前、NameForAGResource は AG リソースの名前です。
順序制約を作成して、IP アドレスよりも前に AG リソースが稼働するようにします。コロケーション制約により順序制約が暗黙に示されますが、これによって適用されます。
```
sudo pcs constraint order promote <NameForAGResource>-master then start <NameForIPResource>
```
ここで、NameForIPResource は IP リソースの名前、NameForAGResource は AG リソースの名前です。

次の構文を使用して AG リソースを作成します。

primitive <NameForAGResource> \
ocf:mssql:ag \
params ag_name="<AGName>" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster <NameForAGResource> \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit

ここで、NameForAGResource は AG のこのクラスターリソースに付ける一意の名前、AGName は作成された AG の名前です。

リスナー機能に関連付ける AG の IP アドレスリソースを作成します。
```
crm configure \
primitive <NameForIPResource> \
   ocf:heartbeat:IPaddr2 \
   params ip=<IPAddress> \
      cidr_netmask=<Netmask>
```
ここで、NameForIPResource は IP リソースの一意の名前、IPAddress はリソースに関連付けられる静的 IP アドレスです。 SLES では、ネットマスクも指定する必要があります。たとえば、255.255.255.0 では Netmask の値は 24 です。
IP アドレスと AG リソースが同じノードで実行するように、コロケーション制約を構成する必要があります。
```
crm configure <NameForConstraint> inf: \
<NameForIPResource> <NameForAGResource>:Master
commit
```
ここで、NameForIPResource は IP リソースの名前、NameForAGResource は AG リソースの名前、NameForConstraint は制約の名前です。
順序制約を作成して、IP アドレスよりも前に AG リソースが稼働するようにします。コロケーション制約により順序制約が暗黙に示されますが、これによって適用されます。
```
crm configure \
order <NameForConstraint> inf: <NameForAGResource>:promote <NameForIPResource>:start
commit
```
ここで、NameForIPResource は IP リソースの名前、NameForAGResource は AG リソースの名前、NameForConstraint は制約の名前です。

次のステップ

このチュートリアルでは、SQL Server on Linux の可用性グループ (AG) を作成および構成する方法について説明しました。以下の方法を学習しました。

可用性グループを有効にします。
AG エンドポイントと証明書を作成します。
SQL Server Management Studio (SSMS) または Transact-SQL を使用して AG を作成します。
Pacemaker の SQL Server ログインとアクセス許可を作成します。
Pacemaker クラスターに AG リソースを作成します。

アップグレードやフェールオーバーなど、ほとんどの AG 管理タスクについては、以下を参照してください。

SQL Server on Linux での HA 可用性グループの操作

SQL Server on Linux の可用性グループを作成および構成する

前提条件

可用性グループ機能を有効にする

mssql-conf ユーティリティを使用する

mssql ファイルを編集する

SQL Server を再起動する

可用性グループのエンドポイントと証明書を作成する

可用性グループを作成する

SQL Server Management Studio を使用します

Transact-SQL の使用

例 A - 構成専用レプリカの 2 つのレプリカ ([外部] クラスタータイプ)

例 B - 読み取り専用ルーティングの 3 つのレプリカ ([外部] クラスタータイプ)

例 C - 読み取り専用ルーティングの 2 つのレプリカ ([なし] クラスタータイプ)

Pacemaker クラスターに可用性グループのリソースを作成する (外部タイプのみ)

次のステップ

フィードバック

フィードバック

その他のリソース

SQL Server on Linux の可用性グループを作成および構成する

前提条件

可用性グループ機能を有効にする

mssql-conf ユーティリティを使用する

mssql ファイルを編集する

SQL Server を再起動する

可用性グループのエンドポイントと証明書を作成する

可用性グループを作成する

SQL Server Management Studio を使用します

Transact-SQL の使用

例 A - 構成専用レプリカの 2 つのレプリカ ([外部] クラスター タイプ)

例 B - 読み取り専用ルーティングの 3 つのレプリカ ([外部] クラスター タイプ)

例 C - 読み取り専用ルーティングの 2 つのレプリカ ([なし] クラスター タイプ)

Pacemaker の SQL Server ログインおよびアクセス許可を作成する

Pacemaker クラスターに可用性グループのリソースを作成する (外部タイプのみ)

次のステップ

フィードバック

フィードバック

その他のリソース

例 A - 構成専用レプリカの 2 つのレプリカ ([外部] クラスタータイプ)

例 B - 読み取り専用ルーティングの 3 つのレプリカ ([外部] クラスタータイプ)

例 C - 読み取り専用ルーティングの 2 つのレプリカ ([なし] クラスタータイプ)