SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Server v.Next CTP 1.3 の AlwaysOn の機能拡張

leave a comment

昨日の投稿で、SQL Server v.Next CTP 1.3 の Linux の AlwaysOn について記載をしました。

現状公開されている情報は、Always On Availability Group for SQL Server on Linux からの一連のドキュメントになるかと。
MS のブログでのアナウンスは、SQL Server on Linux: Mission-critical HADR with Always On Availability Groups になっています。

今回の CTP で拡張された機能としては、What’s New in SQL Server vNext で記載されている、以下の内容となります。


SQL Server Database Engine

SQL Server v.Next に関しては、SQL Server on Linux が目立っていますが、これらの情報は SQL Server on Windows でも共通の情報となっており、Windows 版の SQL Server でも確認することが可能です。

AlwaysOn に関しては、以下の機能拡張が行われています。

  • Cluster-less Availability Groups support added.
  • Minimum Replica Commit Availability Groups setting added.
  • Availability Groups can now work across Windows-Linux to enable cross-OS migrations and testing.

 

Cluster-less Availability Groups support added.

詳細なクォーラムなどの仕組みがわかっていないのですが、WSFC を構築しなくても可用性グループが使用できるようになっています。

この機能は、Linux 向けの可用性グループの設定時 (Always On Availability Group for SQL Server on Linux) にも、使用されています。

可用性グループを作成する際に、「CLUSTER_TYPE = NONE」という設定が可能となっています。
# ALTER でも使用できるオプションですが、現状の ALTER のドキュメントには、まだ記載されていないようです。

機械翻訳されたドキュメントでは、以下のような記載となっています。

CLUSTER_TYPE
SQL Server vNext CTP 1.3 で導入されました。 場合は、可用性グループで、Windows Server フェールオーバー クラスター (WSFC) を識別するために使用されます。 可用性グループが WSFC に属しているサーバー上にある場合は、WSFC に設定します。 可用性グループのクラスターの調整、WSFC を使用していない場合は、[なし] に設定します。 たとえば、ときに可用性グループ、Linux サーバーです。

Linux では、WSFC を使用できないため、「CLUSTER_TYPE = NONE」で作成する必要があり、Configure Always On Availability Group for SQL Server on Linux でも、この方法で可用性グループが作成されています。

Linux 版の可用性グループに関しては、

  • 証明書を使用したエンドポイント
  • クラスターを使用しない可用性グループ

の二つは使われているようです。

詳細な仕組みが記載されているドキュメントがないので、サーバーのノード障害が発生したタイミングの動作がわかっていないのですが、Windows 版でも使用することができました。

実際に、可用性グループを構築した際に取得した情報がこちらです。

WSFC は構築していないため、WSFC 関連の情報はありませんが、可用性グループが構築されていることが確認できます。
sys.dm_hadr_cluster (Transact-SQL) でクォーラムの情報が確認できるので、取得してみたのですが、DMV の情報では、「ノードマジョリティ」が使われているようですね。
image

クラスターが使われていない状態のフェールオーバーの制御がどのようになっているのかが、理解できていないのでこの辺は情報を、キャッチアップする必要があると思っています。

Configure Ubuntu Cluster for SQL Server Availability Group の情報に記載されている「Pacemaker」との組み合わせありきなのかもしれませんが、この辺の情報がまだ理解できていません。

あと、リスナーの作成についての記載が、現状内容なのでこれについても確認が必要ですね。
Linux 版の場合は、Pacemaker の Virtual IP 経由での接続になるのかも。
# Windows 版はどうするかはよくわかっていませんが。

 

Minimum Replica Commit Availability Groups setting added.

こちらも可用性グループの設定時に追加されたオプションとなります。

「REQUIRED_COPIES_TO_COMMIT = { integer } 」が設定できるよう雲丹なっています。

REQUIRED_COPIES_TO_COMMIT
SQL Server vNext CTP 1.3 で導入されました。 プライマリがトランザクションをコミットする前にコミットするために必要なセカンダリ レプリカの最小数を設定するために使用します。 SQL Server のトランザクションがセカンダリ レプリカの最小数は、トランザクション ログが更新されるまでに待機することを保証します。 既定値は、SQL Server 2016 のと同じ動作は、0 です。 最小値は 0 です。 最大値は、レプリカから 1 を引いた数です。 このオプションは、同期コミット モードのレプリカに関連しています。 同期のセカンダリ レプリカ上のライトがレプリカ データベースのトランザクション ログにコミットされるまで、プライマリ レプリカの待機に書き込みますレプリカが同期コミット モードでとします。 同期セカンダリ レプリカをホストする SQL Server が応答しなくなった場合、プライマリ レプリカをホストする SQL Server は同期されていないと、続行、そのセカンダリ レプリカをマークします。 応答しないデータベースがオンラインに戻ったときに「と同期されていません」状態になり、レプリカは、プライマリできるように同期再度まで異常としてマークされます。 この設定により、プライマリ レプリカは、レプリカの最小数が各トランザクションをコミットするまで続行されません。 レプリカの最小数が使用できない場合は、プライマリ上のコミットは失敗します。

同期コミット時に必要となる、コミット数の調整が可能となっているようです。
Configure Always On Availability Group for SQL Server on Linux に以下のように記載されています。

In some cases, a SQL Server availability group in synchronous commit mode on Linux may be vulnerable to data loss. See the following details.

ドキュメントを読んだ感じでは、Pacemaker を使用している場合のデータ損失への対応としての利用を想定しているようなのですが、Pacemaker と可用性グループの連携の動作が理解できていないので、これについても調査が必要ですね…。

ちなみに、ドキュメントの誤記があって、「REQUIRED_COPIES_TO_COMMIT」は、WITH ではなく、SET が正しいです。

ALTER AVAILABILITY GROUP [ag1] WITH (REQUIRED_COPIES_TO_COMMIT = 2)
↓
ALTER AVAILABILITY GROUP [ag1] SET  (REQUIRED_COPIES_TO_COMMIT = 2)

 

Availability Groups can now work across Windows-Linux to enable cross-OS migrations and testing.

SQL Server on Linux で可用性グループが構築できるようになりましたので、クロスプラットフォームで可用性グループによるデータ同期ができるようになりました。

これにより、SQL Server on Linux の環境にデータマイグレーションが可能になるのかと。

SQL Server on Linux: Mission-critical HADR with Always On Availability Groups に書かれている内容がベースとなると思います。

こちらに関しては、今後も機能拡充が行われるようですが、分散型可用性グループを使用した、SQL Server on Linux へのデータマイグレーションやテストを実施するようなシナリオで利用できるようです。

  • Windows の SQL Server 2016 の可用性グループ + Linux の v.Next の可用性グループ
  • Windows の SQL Server 2016 の分散型可用性グループ + Linux の v.Next の分散型可用性グループ
  • Windows の v.Next の可用性グループ + Linux の v.Next の可用性グループ
  • Windows の v.Next の分散型可用性グループ + Linux の v.Next の分散型可用性グループ

というような、どのような組みあわせのシナリオで使用できるかが見えていないので、マルチバージョン / マルチプラットフォームの組み合わせについても調査が必要かと。


可用性グループは、データベースのトランザクションログのレコードを連携することで同期を行う仕組みですので、Windows / Linux 関係なく、ログの連携ができれば同期ができます。

分散型可用性グループの場合、リスナー間を接続する形になりますので、SQL Server on Linux 側のプライマリの判断方法がまだ調べられていません。

分散型可用性グループでなく、Windows / Linux の v.Next のサーバーを組み合わせての同一可用性グループ内のクロスプラットフォーム配置をしてみたところで来たので、サポートされる構成の情報については少し気にしておきたいです。

image

Windows と Linux で、直接シード処理を使用した初期データ同期を行う場合、DB の保存パスについては気を付けておいた方がよいかと。

今回は、Windows の環境を起点に、クロスプラットフォームの可用性グループを作成したのですが、その際の DB のパスについては、Unix でも使用できるパスで設定して、直接シードを行わせています。

image

SQL Server on Linux だけでなく、Windows 環境観点での v.Next の情報のキャッチアップもきちんとしないといけないなと思った、今日この頃です。

Written by masayuki.ozawa

2月 19th, 2017 at 12:26 pm

Posted in SQL Server

Tagged with

Leave a Reply

*