JBODを使用した単一ディスク障害からの復旧

JBOD(Just a bunch of disks)を使用してディスク・アレイの単一ディスク障害から復旧するための手順。

JBOD(Just a bunch of disks)を使用してディスク・アレイの単一ディスク障害から復旧するための手順。

DataStax Enterpriseでは、JBODアレイの単一ディスクの損失が原因では障害が発生しないと考えられますが、以下の場合に一部の読み取りおよび書き込みが失敗することがあります。
  • 操作の整合性レベルがALLである。
  • 要求対象となる、または書き込み対象となるデータが欠陥のあるディスクに格納されている。
  • コンパクション対象のデータが不良ディスク上にある。

単にディスクを交換し、DataStax Enterpriseを再起動し、nodetool repairを実行することで解決できる場合もあります。ただし、ディスクのクラッシュによってシステム・テーブルが破損した場合は、アレイのその他のディスクから不完全なデータを削除する必要があります。これを行うための手順は、クラスターがVnodeを使用しているか、または単一トークン・アーキテクチャーを使用しているかによって異なります。

cassandra-env.sh

cassandra-env.shファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra-env.sh
tarボール・インストール installation_location/resources/cassandra/conf/cassandra-env.sh

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra.yaml
tarボール・インストール installation_location/resources/cassandra/conf/cassandra.yaml

手順

  1. ノードに不良ディスクが存在することを確認し、その影響を受けるノードのログを確認してディスクを特定します。
    ディスク障害はFILE NOT FOUNDエントリーに記録されており、障害が発生したマウント・ポイントまたはディスクを特定できます。
  2. ノードが実行されている場合は、DSEを停止し、ノードをシャットダウンします。
  3. 不良ディスクを交換し、ノードを再起動します。
  4. ノードを再起動できない場合:
    1. ノードをブートストラップせずにDataStax Enterpriseの再起動を試行します。
      パッケージ・インストール:
      1. 次のオプションをcassandra-env.shファイルに追加します。
        JVM_OPTS="$JVM_OPTS -Dcassandra.allow_unsafe_replace=true
      2. DataStax Enterpriseをサービスとして起動
      3. ノードのブートストラップ後、cassandra-env.shから-Dcassandra.allow_unsafe_replace=trueパラメーターを削除します。
      4. DataStax Enterpriseをサービスとして起動

      tarボール・インストール:

      • 以下のオプションを指定して、DataStax Enterpriseを起動します。
        sudo bin/dse cassandra Dcassandra.allow_unsafe_replace=true
        tarボールのパス:
        installation_location
  5. DataStax Enterpriseが再起動したら、ノード上でnodetool repairを実行します。リペアが成功しなかった場合は、ノードを置き換えます
  6. リペアが成功すると、ノードはプロダクションに復元されます。それ以外の場合は、「7」または「8」に進んでください。
  7. vnodeを使用しているクラスターの場合:
    1. 影響を受けるノードで、機能しているドライブごとにsystemディレクトリーを消去します。
      3ディスクJBODアレイを持つノードの例:
      -/mnt1/cassandra/data 
      -/mnt2/cassandra/data
      -/mnt3/cassandra/data
      mnt1が失敗した場合:
      rm -fr /mnt2/cassandra/data/system && 
      rm -fr /mnt3/cassandra/data/system
    2. 4」で説明されているように、ブートストラップせずにDataStax Enterpriseを再起動します。
      -Dcassandra.allow_unsafe_replace=true
    3. ノード上でnodetool repairを実行します。

      リペアが成功すると、ノードはプロダクションに復元されます。リペアが成功しなかった場合は、ノードを置き換えます

  8. クラスターの単一トークン・ノードの場合:
    1. クラスターの動作中のノードのいずれかで、nodetool ringを実行して、リペア済みのノードのトークンのリストを取得します。
      nodetool ring | grep ip_address_of_node | awk ' {print $NF ","}' | xargs
    2. nodetool ringの出力をスプレッドシートにコピーします(スペース区切り)。
    3. 出力を編集すると、トークンのリストは維持されますが、他のカラムは削除されます。
    4. 新しいディスクを含むノード上で、cassandra.yaml ファイルを開き、トークンを(カンマ区切りリストとして)initial_tokenプロパティに追加します。
    5. 既存のノードに合わせて、新しいノードのデフォルトでないその他の任意の設定を変更します。diffコマンドを使用して、ノード間の違いを見つけて出力します。

      リペアが成功すると、ノードはプロダクションに復元されます。リペアが成功しなかった場合は、ノードを置き換えます

    6. 影響を受けるノードで、機能しているドライブごとにsystemディレクトリーを消去します。
      3ディスクJBODアレイを持つノードの例:
      -/mnt1/cassandra/data 
      -/mnt2/cassandra/data
      -/mnt3/cassandra/data
      mnt1が失敗した場合:
      rm -fr /mnt2/cassandra/data/system && 
      rm -fr /mnt3/cassandra/data/system
    7. 4」で説明されているように、ブートストラップせずにDataStax Enterpriseを再起動します。
      -Dcassandra.allow_unsafe_replace=true
    8. ノード上でnodetool repairを実行します。

      リペアが成功すると、ノードはプロダクションに復元されます。リペアが成功しなかった場合は、ノードを置き換えます