SE の雑記

ちょっとしたメモとして。
SQL Server on Linux でも可用性グループを構築することが可能ですが、RTM 直後の段階では、自動フェールオーバーが可能な状態で構築をするためには「SQL Server を 3 台で構成」する必要がありました。
詳細については、可用性グループの構成の高可用性とデータの保護 に記載されています。

次の画像はドキュメントの内容を抜粋したものとなりますが、「3 台」で構成している場合、完全同期されているセカンダリレプリカが 1 台保証されている構成とすると、自動フェールオーバーが可能であり、自動フェールオーバー後に読み取り/書き込みが可能となっています。

それでは「2 台」で構築した場合はどうなるでしょうか。
2 台構成の場合、完全同期されているセカンダリレプリカが 1 台保証されている構成とすると、自動フェールオーバーは可能なのですが、セカンダリが復帰するまでデータベースへのアクセスが制限された状態となります。

ここまでが、RTM 直後の GA 版の構成となっていたのですが、CU1 になって可用性グループに参加するノードの可用性モードに「CONFIGURATION_ONLY」というモードが追加されました。
3 台構成とはなるのですが、その中の 1 台を「構成のみ」の可用性モードとすることができるようになります。

この構成とした場合、完全に同期されたセカンダリが存在することを保証していなくても、自動的なフェールオーバーが可能となっています。

RTM の 3 台構成の時の大きな違いとしては「構成のみ」の可用性モードを設定するノードについては「Express Edition」を利用することができる点です。
最初に紹介した 3 台構成については、各 SQL Server が実際にデータの同期を行う構成となっているため「すべて同じエディション」で構成する必要があり、3 台分の SQL Server のコストがかかることになります。
CU1 で追加された「構成のみ」のノードについては、無償版の Express Edition で構成ができるため、このノードについてはコストを抑えることができます。
構成としては、ミラーリングと同じ考えですよね、これ。
構成のみのノードについては同期を行うためのエンドポイントは「WITNESS」として作成を行います。

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_IP = (0.0.0.0), LISTENER_PORT = 5022)
    FOR DATA_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
GO
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
GO
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [dbm_login];

 
可用性グループを作成するときには、「CONFIGURATION_ONLY」を作成することで、構成のみのノードを含んだ可用性グループを作成することができます。

CREATE AVAILABILITY GROUP [SoLAG1]
    WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
    FOR REPLICA ON
        N'SoL01' WITH (
            ENDPOINT_URL = N'tcp://SoL01:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC,
            SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
            ),
        N'SoL02' WITH (
            ENDPOINT_URL = N'tcp://SoL02:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC,
            SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
            ),
        N'SoL03' WITH (
            ENDPOINT_URL = N'tcp://SoL03:5022',
            AVAILABILITY_MODE = CONFIGURATION_ONLY
            )
GO

検証していたところ、この「構成のみのノード」についても、pacemaker のノードとして追加しておく必要があるようです。
実際の設定がこちらです。

上記の画像では「SoL02」がマスター (プライマリ) となっています。
SSMS のダッシュボードの上の表示も同じですね。

それでは「SoL02」をシャットダウンしてみます。


SoL01 に自動フェールオーバーし、アクセス可能な状態になっていますね。
Express をウィットネスとして、Sequence Number の整合性を取りながらフェールオーバーを実施するという仕組みになっているのですが、この辺で Pacemaker のスコアも関係していて、実運用を想定するとまだまだ調査しなくてはいけないことが多いですね。
いろいろと情報追いながら検証しているのですが、今まで Linux 触っていなかったツケがいろいろと出てきており、検証するのにかなり時間がかかっています…。