リリース当初からドキュメントがかなり更新されており、ビジネス継続性とデータベース復旧 – SQL Server on Linux からの一連のドキュメントを確認しておけばよいはずではありますが、個人的に引っかかったところを。
可用性グループでしか試していませんが、FCI (Failover Cluster Instance) の構成を手動フェールオーバーした場合も同様かと思います。
詳細については SQL Server on Linux の HA 可用性グループを操作します。SQL Server on Linux の HA 可用性グループを操作します。 を確認してください。
このドキュメント、CTP のリリース時点から大幅に情報が加筆されていますので、プレビューリリース当初に目を通しただけの方は、再度情報を確認した方がよいかと思います。
可用性グループの初期構築が完了した後に、フェールオーバーが実行可能かを確認するために、次のコマンドを実行して動作確認をすることがあるかと思います。
pcs resource move ag_cluster-master SoL02 --master
これで指定したノードにフェールオーバーされますが、注意点として「フェールオーバー後のノードが優先的な所有者として設定される (Score = INFINITY)」というような動作が行われます。
SoL01 / SoL02 というノードが存在していた場合を例とすると次のようになります。
- SoL01 がプライマリの状態で SoL02 に手動でフェールオーバーを実行
- SoL02 の Score が INFINITY として設定される制約「cli-prefer-ag_cluster-master」が設定される
この状態で、SoL02 の SQL Server のサービスが停止すると SoL01 にフェールオーバーが行われます。
ここまでは問題ないのですが、「SoL02 が復帰」した直後の動作で注意しなくてはいけない点があります。
上述の流れの「2.」で、SoL02 の Score として INFINITY が設定されているため、優先的に起動するノードとして認識が行われています。
そのため、手動フェールオーバーを実行した場合、手動フェールオーバー先のノードが復旧し、自動フェールバックが可能な状態になった場合は、スコアの設定状況に従い、自動フェールオーバーされます。
「SoL02 に手動フェールオーバー」→「SoL02 の mssql-server を停止」した状態がこちらになります。
「SoL02」が 「Stopped」状態になり、「SoL01」が「Master」に昇格 (Promote) されていることが確認できます。
それでは、この状態で「SoL02」の mssql-server を開始してみます。
SQL Server が開始したら、リソース障害のフェイルカウントをクリアするため「pcs resource cleanup」を実行します。
そうすると、
- SoL01 がマスターから降格 (Demote) される
- SoL02 がマスターに昇格 (Promote) される
というような動作が行われます。
これは、制約 (Constraint) として、SoL02 の Score (優先順位) が高順位となる INIFITY に設定されているため、SoL02 がノードで起動できる状態になったら、自動的にフェールバックされるためです。
そのため、冒頭で紹介した SQL Server on Linux の HA 可用性グループを操作します。 では、次のような記載があります。これは、自動フェールバックの設定を削除するための記載ですね。
重要
リソースを手動でフェールオーバーした後は、移動中に自動的に追加される場所の制約を削除する必要があります。
次のコマンドを実行することで、手動フェールオーバーを実施した場合に設定された制約のみを削除することができます。
sudo pcs constraint remove cli-prefer-ag_cluster-master
これにより、手動フェールオーバー先に設定されていた、制約が削除されるため、フェールオーバー先が復旧しても自動フェールバックは行われなくなります。
SQL Sever on Linux の可用性環境は、現状は Pacemaker を利用することになりますが、スキルアップデートが必要になる個所が結構あって、地味に大変ですね…。
私が調べてメモした内容については、Pacemaker 操作方法メモ として公開してみましたので、今後触りだす方のご参考になれば幸いです。