SE の雑記

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

SQL Server on Linux のプライマリへの昇格の制御について

leave a comment

昨日、SQL Server 2017 CU1 の Linux 版の可用性グループの拡張 を書きましたが、プライマリへの昇格の制御について、少し補足をしておきたいと思います。

実際にはこの辺りは、Pacemaker のリソースエージェント経由での制御となっているため、独自のクラスター管理の仕組みを作るのでない限りは、あまり意識する必要はないかと。

詳細については ペースに対する SQL Server エージェントのリソースを理解します。 に記載されています。

SQL Server 2017 CTP 1.4 から、sys.availability_groups が拡張され「sequence_number」という列が増えています。

この列の情報を使用して、昇格 (Promote) できるかの判断が行われています。

SELECT 
	@@SERVERNAME as Server, name, cluster_type_desc, required_synchronized_secondaries_to_commit, sequence_number 
FROM 
	sys.availability_groups

 

通常、この値は同期モードの可用性グループで構成している場合はすべてのノードで同一の値となります。

image

この値は、「構成のみ」のノードにも複製されており、3 台構成で、自動フェールオーバーが可能なのも、この値を使用して「どのノードが最新のノードか」を把握できるようにしているからかと。

「構成のみ」のノードについては、データベースの複製は行われませんが、可用性グループの構成については、情報の複製が行われており、この情報については、他のノードと同期をしている必要があります。

「sequence_number」が最新のノード以外はプライマリに昇格できないように、Pacemaker のリソースエージェントが制御をしているようですね。

Pacemaker のリソースエージェントは、sequence_number が低いノードをプライマリに昇格することができないように制御をしているようです。

 exitreason='2017/12/07 23:26:22 Local replica has sequence number 141733920784 but max sequence number is 146028888066, so it cannot be prom',
    last-rc-change='Thu Dec  7 23:26:16 2017', queued=0ms, exec=5910ms

独自のクラスターマネージャーを作成する場合は、この辺も意識しないといけないのでしょうね。

Written by masayuki.ozawa

12月 7th, 2017 at 11:33 pm

Posted in SQL Server

Tagged with ,

Leave a Reply

*