障害の検知と復旧

システム内の別のノードがダウンしているか、復旧しているかどうかを、ゴシップ状態と履歴からローカルに特定するための方法。

障害の検知とは、システム内の別のノードがダウンしているか、復旧しているかどうかを、ゴシップ状態と履歴からローカルに特定するための方法です。Cassandraはこの情報を使用して、到達不能なノードにクライアント要求をルーティングするのを可能な限り回避します（Cassandraは、動的スニッチを通じて、稼働しているけれどもパフォーマンスが低下しているノードに要求をルーティングするのを回避できます）。

ゴシップ・プロセスは、他のノードから、状態情報を直接的に（直接の通信先ノードから）および間接的に（二次情報、三次情報などとして）得て追跡します。Cassandraは、ノードで障害が発生していると判定する固定しきい値の代わりに、累積検知メカニズムを使用して、ネットワークのパフォーマンス、ワークロード、および状態履歴を考慮したノードあたりしきい値を計算します。ゴシップ交換中、各ノードは、クラスターの他のノードからのゴシップ・メッセージの到着間隔のスライディング・ウィンドウを維持します。phi_convict_thresholdプロパティを構成して、障害検知の感度を調整します。値を低くすると、応答しないノードがダウンしているとマークされる可能性が高くなり、一方、値を高くすると一時的な障害によりノード障害と判定される可能性が低くなります。ほとんどの場合はデフォルト値を使用しますが、Amazon EC2の場合には値を10または12まで上げます（ネットワークの頻繁な輻輳のため）。不安定なネットワーク環境では（EC2などで時々）、この値を10〜12に上げることで偽障害を防止しやすくなります。12よりも大きい値、または5よりも小さい値は推奨しません。

ノードの障害は、ハードウェアの障害やネットワークの停止などさまざまな原因で発生します。ノードの停止は、ほとんどの場合一時的なものですが、長期にわたることもあります。ノードの停止は、クラスターからの永久的な離脱を意味することはまれであるため、リングからのノードの永続的な除去という結果にはなりません。他のノードは、障害のあるノードが復旧したかどうかを確かめるために、定期的に接続を再確立しようと試みます。クラスターのノードのメンバーシップを永続的に変更するには、管理者がnodetoolユーティリティまたはOpsCenterを使用して、明示的にCassandraクラスターにノードを追加またはクラスターから除去する必要があります。

停止の後でノードがオンラインに復帰したとき、そのノードが維持しているレプリカ・データの書き込みを取りこぼしている可能性があります。nodetool repairを使用したヒンテッド・ハンドオフや手動リペアなど、失われたデータを復旧するためにリペア・メカニズム があります。機能停止の長さは、データの一貫性を保つためにどのリペア・メカニズムを使用するかによって決まります。