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

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

DataStax Enterpriseでは、JBODアレイの単一ディスクの損失が原因では障害が発生しないと考えられますが、以下の場合に一部の読み取りおよび書き込みが失敗することがあります。

操作の整合性レベルがALLである。
要求または書き込み対象のデータが不良ディスクに格納された。
コンパクション対象のデータが不良ディスク上にある。

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

手順

DataStax Enterprise 5.0以前を使用してクラスター内のノードでディスク障害が発生した場合は、ノードを置き換えます。

ノードに不良ディスクが存在することを確認し、その影響を受けるノードのログを確認してディスクを特定します。

ディスク障害はFILE NOT FOUNDエントリーに記録されており、障害が発生したマウント・ポイントまたはディスクを特定できます。
ノードが実行されている場合は、DSEを停止し、ノードをシャットダウンします。
不良ディスクを交換し、ノードを再起動します。
ノードを再起動できない場合：
1. ノードをブートストラップせずにDataStax Enterpriseの再起動を試行します。
  パッケージおよびInstaller-Servicesのインストール：
  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ボールおよびInstaller-No Servicesのインストール：
  - 以下のオプションを指定して、DataStax Enterpriseを起動します。
```
$ sudo bin/dse cassandra Dcassandra.allow_unsafe_replace=true
```
    tarボールおよびInstaller-No Servicesのパス：
```
installation_location
```
DataStax Enterpriseが再起動したら、ノード上でnodetool repairを実行します。再起動しない場合は、ノードを置き換えます。
リペアが成功すると、ノードは実稼働に復元されます。それ以外の場合は、「7」または「8」に進んでください。
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を実行します。
  
  リペアが成功すると、ノードは実稼働に復元されます。リペアが成功しなかった場合は、ノードを置き換えます。

クラスター単一トークン・ノードの場合：

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

リペアが成功すると、ノードは実稼働に復元されます。リペアが成功しなかった場合は、ノードを置き換えます。
影響を受けるノードで、機能しているドライブごとに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
```
「4」で説明されているように、ブートストラップせずにDataStax Enterpriseを再起動します。
```
$ -Dcassandra.allow_unsafe_replace=true
```

ノード上でnodetool repairを実行します。

リペアが成功すると、ノードは実稼働に復元されます。リペアが成功しなかった場合は、ノードを置き換えます。

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール	/etc/dse/cassandra/cassandra.yaml
tarボール・インストールInstaller-No Servicesインストール	`installation_location`/resources/cassandra/conf/cassandra.yaml

cassandra-rackdc.propertiesファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール	/etc/dse/cassandra/cassandra-rackdc.properties
tarボール・インストールInstaller-No Servicesインストール	`installation_location`/resources/cassandra/conf/cassandra-rackdc.properties

cassandra-topology.propertiesファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール	/etc/dse/cassandra/cassandra-topology.properties
tarボール・インストールInstaller-No Servicesインストール	`installation_location`/resources/cassandra/conf/cassandra-topology.properties

cassandra-env.shファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール	/etc/dse/cassandra/cassandra-env.sh
tarボール・インストールInstaller-No Servicesインストール	`installation_location`/resources/cassandra/conf/cassandra-env.sh