はじめに
全8回、第7弾です。
Technical Description — Galera Cluster Documentation
NODE FAILURE AND RECOVERY
クラスタに接続できなくなったとき、各ノードでの操作は失敗します。これは様々な原因によって発生します。例えば、ハードウェア障害やソフトウェアのクラッシュ、ネットワークの切断やstate transferの失敗など。いずれもクラスタ内ノード間の通信を阻害は、ノード障害という概念の背後に存在します。ノード障害を理解することはリカバリを計画するのに役立つでしょう。
DETECTING SINGLE NODE FAILURES
ノード障害が起きた時の唯一のサインは他のノードから見てそのノードとの接続が失われることでしょう。ノードはクラスタのPrimary Componentとのメンバシップが失われた時、そのノードは故障したとみなされます。これは、Primary Componentから見て、長時間そのノードが確認されないノードは故障とみなす考え方からくるものです。障害が発生したノード自身から見ると、障害が起きていなかったとしても、Primary Conponentとの接続が切断されます。
ノードを監視するサードパーティのツールは存在しますが、-例えばping, Heartbeat, Pacemekerなど- それらはノードの故障見積もりが大きくズレているかもしれません。これらのツールはGalera Clusterのグループコミュニケーションに参加せず、Primary Componentを認識しません。
Galera Clusterノード状態を監視したいなら、wsrep_local_stateステータスを定期関しするか、Notification Commandを使ってください。
クラスタはノードから最後に受信したネットワークパケットより接続性を決定します。クラスタの確認間隔はevx.inactive_check_periodパラメタで設定可能です。確認中はクラスタが最後にネットワークパケットを受信した時間よりevs.keepalive_periodパラメタの値が大きければ、heartbeat beconを送信します。クラスタがevs.suspect_timeoutパラメタの値よりも長い間隔ネットワークパケットを受信しない場合、ノードは(故障が)疑わしいと宣言されます。Primary Componentのすべてのメンバはその疑いを確認すると、そのノードはアクティブでないと判断します、すなわち、故障です。
evs.inactive_timeout間隔より長い時間メッセージを受け取らない場合、ノードは同意に関係なく故障したと宣言されます。故障ノードはメンバシップがすべてのメンバーととれるまでは操作できない状態になります。(訳注：Non-Primary状態でしょう) メンバが稼働ノードとの同意に達することができないなら、クラスタ操作を行うにはネットワークが不安定すぎます。
ノード間の関係は、以下のオプションの値を満たす時に達成します。
evs.keepalive_period <= evs.inactive_check_period evs.inactive_check_period <= evs.suspect_timeout evs.suspect_timeout <= evs.inactive_timeout evs.inactive_timeout <= evs.consensus_timeout
注意：メッセージやheatbeat beconの送信に失敗する、鈍感なノード、-例えば、とても重たいスワッピングが発生しているような- もまたはっきりと故障ノードとなるでしょう。これは他のクラスタに残ってるノードの操作を妨げます。このような望ましくない振る舞いを発見した場合、timeoutパラメタを増やしましょう。
CLUSTER AVAILABILITY VS. PARTITION TOLERANCE
CAP定理のうち、Galera Clusterはデータの安全と一貫性に重きを置いています。これはクラスタ可用性と対断耐性との間のトレードオフを意味します。WANのような不安定なネットワークを使用している場合、evs.suspect_timeoutとevx.inactive_timeoutの値が小さいと、誤った故障検知をしてしまいますが、一方で大きい値をとると、実際に故障した場合の可用性が担保できない時間が長くなってしまいます。
本質的にこれが意味することは、evs.suspect_timeoutパラメタはノード故障検知に必要な最小限の時間を指定するべきです。この間隔の間、クラスタは一貫性の制約のために使用できなくなります。
RECOVERING FROM SINGLE NODE FAILURE
あるノードがクラスタで故障した場合、他のノードは通常通りの操作を続けます。ノードがオンラインに復帰したときは、クラスタに戻る前に、自動的に他のノードとの同期が行われます。
1つのノードが故障してもデータ消失はないのです。
State Transfer Failure
単一ノードの故障はstate snapshot transfer(SST)の失敗でも発生します。この失敗は受信ノードを使用不能にし、state transferの失敗を検知した時受信ノードは(受信を)破棄します。
ノードがmysqldumpを使っている場合は、再始動は手動でのテーブルのリストアになるでしょう。rsyncをSSTに使っている場合は、問題は起きません。データベースサーバを特に操作する必要はありません。
おわりに
クラスタ内での単一ノード障害の考え方と、障害を検知するパラメタの説明がされていました。言いたいことは「1つのノードが壊れてもクラスタとしては問題ないよ」になると思いました。
