CentOS 7 を使用しているため、通常のハートビート設定から pacemker に切り替えました。
主に、1 つのノードでアクティブで、フェイルオーバーが発生した場合に 2 番目のノードに切り替わる IP リソースがあります。また、フェイルオーバーが発生した場合にいくつかのスクリプトを実行します。特別なことは何もありません。
リソースを常にプライマリノードで起動するには、
pcs constraint location Cluster_IP prefers server1=master-server
私も使っています
pcs resource defaults resource-stickiness=INFINITY
フェイルオーバー後にリソースが元に戻るのを防ぐためです。
マスターに障害が発生した場合（たとえば、ハードウェア障害）、これは正常に機能します。
フェイルオーバーに多少の時間がかかっても問題ないので、短時間のスプリット ブレインの場合に備えて、何らかの遅延を実装したいと思います。
スレーブは、マスターがこの約 2 分以内に再びアクセス可能になった場合に備えて、何かを実行する前に約 2 分間待機してから引き継ぐ必要があります。
どうすれば一番いい方法なのかと思いました。
答え1
Corosync でトークン タイムアウトを 10 秒以上に設定したことはありませんが、tokenの値を(ミリ秒単位で 120 秒) に増やしたり設定したりすることができます。corosync.conf詳細については、の;セクションで定義する必要があります。120000tokentotem{}corosync.confman corosync.conf
これにより、ネットワークがダウンしたときに Corosync が 120 秒間ノードが停止していると宣言することが防止されます。
答え2
リソースの監視間隔は （ は秒数）で変更できますop monitor interval=Ns。N次に、migration-thresholdリソースの を に設定します。 に設定すると、監視間隔で最初の障害が発生するタイミングに応じて、合計で 120 ～ 240 秒の遅延が発生する可能性があることに2注意してください。120s
これには他の注意点があり、適用された失敗カウンターはmigration-threshold成功時にリセットされません。これを行うには、設定するか手動で介入する必要もありますfailure-timeout。
op monitor interval=120s、、migration-threshold=2およびfailure-timeout=121s設定ではresource-stickiness、これが期待どおりの機能を提供し、元のマスターが回復したときに障害カウンターがどのように動作するかを確認するためにテストする必要があります。手動による介入が必要になる可能性がありますが、100%確信はありません。