メタデータの末尾にスキップ
メタデータの先頭に移動

この章では、Clustrixがどのように様々な種類の故障を扱うかを説明し、それらが起きた時にリカバーするための一番よい方法を教えます。


イーサネット障害

もしノードがイーサネットワークポートと通信できない場合、例えば不慮のケーブル抜け、スイッチの設定ミス、あるいはNIC障害、手動ではない介入が必要です。クラスタは以下のアクションをとります:

  • 追加の接続が障害のあるインスタンスに割り当てられないようにする。
  • 障害のあるノードがVIPディレクターの場合、他のノードが自動的にVIPディレクターに選択されます。既存のセッションは透過的に新しいVIPディレクターに移動するでしょう。
  • 障害のあるノードがリプリケーションのスレーブ接続を処理していた場合は、その接続は他のノードに移動させられます。

InfiniBand障害

二つのInfiniBandスイッチが設定されたクラスタは、一つのInfiniBandケーブル、ポートあるいはスイッチの障害に耐えることができます。InfiniBand接続障害の場合、クラスタはただちにトラフィックを代替のInfiniBand接続に切り替えます。 そのような障害が起きた場合、クラスタは新しいメンバーと再調整することになり、結果的にクエリの処理に短時間(秒)の中断が起きます。実行中のクライアントのトランザクション(接続ではありません)はキャンセルおよびロールバックされますが、後続のクエリとトランザクションは正常に実行されます。障害のある接続が回復した後は、クラスタは自動的にその接続を他のInfiniBand障害に備えて利用可能なパスに統合します。

ディスク障害

Clustrixはデータの複数のコピーを保持します。We maintain 2 copies by default, but you may specify as many copies as you like down to the index level using the REPLICAS=X directive in our ALTER and CREATE DDL statements. クラスタがディスク障害を検知すると、システムは自動的にデータの新しいコピーを生成するために再保護オペレーションをスケジュールするでしょう。管理者はデータセットを再保護するためになにもアクションする必要はありません。 テーブルのコピーの数が指定した数を下回り、システムが再保護タスクを完了した場合に、クラスタはさらにアラートを出すでしょう。

どのようなディスク障害の場合でもノードはドライブキャリアの明滅する赤いLEDを表示します。障害のあるディスクを交換するために、単純にそれを取り除きClustrix提供の置き換えディスクを挿入します。Clustrix置き換えディスクは更なる介入無しにシステムがドライブを自動的に組み込むことができる特別な識別子を持っています。ノード上のレプリカの分散をバランスするためにリバランサが自動的にデータをこの新しいドライブに移します。

システムがディスク上にエラーを検知する場合もあります。 しかしながら、ドライブ障害として印をつける閾値以下のエラーであれば、いくつかのユーザクエリが障害のあるデバイスから読み込みしようとして時々エラーを受け取るかも知れません。そのような場合、管理者は利用可能なコピーの数を減らさずにそのデバイスを手動で無効化するかも知れません。システムはそのデバイス上の全てのデータをシステム内のほかのデバイスに安全に移動しようとするでしょう。

-- あるデバイスを無効化するには
mysql> ALTER NODE <nodeid> SOFTFAIL DEVICE <devid>;
 
 
-- 現在 追い立てようとして選択しているデバイスをリスト表示する
mysql> SELECT * FROM system.softfailed_devices;
 
-- 進行中のsoft-failオペレーションを中止するには
mysql> ALTER NODE <nodeid> UNSOFTFAIL DEVICE <devid>;

ノード障害

この章では、二つの種類のノード障害を説明します: 一時的、ノードが短期間オフライン(例えば、クラッシュまたは電源障害による)。恒久的、ノードがハードウェア障害により完全にフェイルし、戻ることが期待できない。

一時的なノード障害

クラスタが個々のノードとなんらかの理由で接触できない場合、クラスタ内の残存するノードはこのノード無しの新しいグループを形成し、クライアントに提供を続けます。リプリケーションスレーブおよびVIPディレクターのような全てのサービスは残存するノードに渡って再割り当てされます。. VIPを経由して接続されたクライアントはこのグループの変更の間ほんの少しだけ利用不可になります。障害のあるノードに分配されたクライアントは再接続しなければなりません。障害のあるノードに直接接続されたクライアントはデータベースに問い合わせることができません。

障害のあるノードが回復した後で、それはクラスタに再び加わり作業を受け付けることができます。障害のあるノードは回復に手動での介入が必要かもしれませんが(例えば、電源の回復)、回復した後でそのノードをクラスタに再統合するのにそれ以上のアクションは必要ではありません。

クラスタがデータの再保護を始める前の10分以内はノードはクラスタにとって利用することができません。10分後、リバランサはディスク障害と同じ戦略をとります: 保護下にあるスライスが残存するノードに渡って分散した新しいレプリカにコピーされます。いくつかあるいは全てのスライスが3つ目のレプリカを作成した後で喪失したノードが回復した場合は、リバランサはそれらの追加されたコピーを取り除きます。

クラスタは、クラスタが完全に保護されるまで障害のあるノードに施された全ての変更を記録します。ノードが素早く戻ってきた場合は、Clustrixは最後にノードが定員だった時からの変更を再生し、その後ノードがクラスタに再加入します。この最適化によりクラスタは再構成無しに素早くノードを再統合することができます。

恒久的なノード障害

10分以上ノードがダウンした場合は、システムはデータを再保護し始めます。再保護プロセスが完了、クラスタから自動的に送信されるアラートメールによって示されます、した後は、システムはデータの喪失無しにどのような単一の障害を切り抜ける事ができます。However, availability of data depends on the cluster being able to attain quorum which requires Q nodes where Q > N/ 2. 定員を計算する目的で喪失したノードはまだクラスタの一部だと見なされます。つまり連続する二つのノード障害を持ちこたえて介入無しに可用性を維持するには、クラスタ内に5つのオリジナルのノードが残っていなければなりません。

従って、3または4ノードのクラスタがノードを喪失した場合は、クラスタを高可用性の状態に戻すために以下のアクションを取らなければなりません。

  1. ノードが恒久的なハードウェア障害によってフェイルしてデータが再保護された場合、ALTER CLUSTERコマンドを発行することでノードをクラスタから落とします。これでクラスタサイズはN-1です。警告: クラスタがデータの再保護を完了するまで喪失したノードを落とさないでください!クラスタにデータ領域を再保護するために必要なディスク容量が無い場合、更なる故障がデータと可用性を失わせる場合があります。4つのノードのクラスタで開始すると、1つのノードを喪失した後で新しい3つのノードクラスタは可用性を維持することができます。しかし、2つのノードのクラスタは1つのノードを喪失することができず、可用性を維持できません。
  2. クラスタに代替のノードを加入するには、ALTER CLUSTERコマンドを発行します。置き換えられたノードは新しいノードIDが与えられます (ノードIDはそのノードが以前クラスタの一部で無かった場合にはクラスタ内で再利用されません)。

ノードのソフトフェイル

クラスタから動作しているノードを取り除きたいことがあるでしょう(たとえば、NIC障害)。以下のコマンドは、クラスタからノードを取り除く前に他のノード上でレプリカが保護されることを確実にします。

mysql> ALTER CLUSTER SOFTFAIL nodeid;


ノードが取り除かれる時にノード上で実行されているクエリは中断されるかも知れないことに注意してください。これはグローバル変数 auto_drop_softfailed_nodes で制御することができます。

ソフトフェイルされるノードを確認するには、以下のコマンドを発行します。

mysql> SELECT * FROM system.softfailed_nodes;
  • ラベルなし
TOP
inserted by FC2 system