デッド・ノードまたはデッド・シード・ノードの置き換え

ハードウェアの故障など、何らかの原因でデッド状態となったノードを置き換える手順。

1. nodetool statusを実行して、ノードがデッドであることを確認します（DN）。

   

2. データ・センター、アドレス、デッド・ノードのラックの設定を記録します。後ほど、使用します。
3. 交換ノードをネットワークに追加して、そのIPアドレスを記録します。
4. デッド・ノードがシード・ノードであった場合、各ノードのクラスターのシード・ノード構成を変更します。
   1. 各ノードの cassandra.yaml ファイルで、seed-providerプロパティ内の- seedsリストからデッド・ノードのIPアドレスを削除します。
   2. デッド・ノードを置き換えるためにクラスターが新しいシード・ノードを必要としている場合、新しいノードのIPアドレスを他のノードの- seedsリストに追加します。
      重要: 保守タスクが増え、ゴシップのパフォーマンスが低下するため、すべてのノードをシード・ノードにすることは推奨しません。ゴシップの最適化は重要ではありませんが、シード・リストを小さくすることを推奨します（データ・センターあたり約3つのノード）。
5. 既存のノードで、新しいノードの設定情報をcassandra.yaml ファイルから収集します。
   • cluster_name
   • endpoint_snitch
   • デフォルトでないその他の設定。 差分ツールを使用して、現在の設定とデフォルト設定を比較します。
6. ラックおよびデータ・センター情報を収集します。
   • クラスターでPropertyFileSnitchを使用する場合は、cassandra-topology.properties ファイルにリストされているラックおよびデータの割り当てを記録するか、このファイルを新しいノードにコピーします。
   • クラスターでGossipingPropertyFileSnitch、Amazon EC2シングルリージョン・スニッチの構成、Amazon EC2マルチリージョン・スニッチの構成、またはGoogle Cloud Platformスニッチの構成が使用される場合は、デッド・ノードのcassandra-rackdc.properties ファイルのラックおよびデータ・センターの割り当てを記録にとります。
7. 新しいノードがすべての前提条件を満たしていることを確認してから、新しいノードにDataStax Enterpriseをインストールしますが、DataStax Enterpriseを起動しないでください。
   注: インストールの手順の説明に従って、クラスターの他のノードに同じバージョンのDataStax Enterpriseがインストールされていることを確認してください。
8. DataStax Enterpriseがノードで自動的に起動した場合、始動時に自動的に追加されたデータを停止し、消去します。
9. 以前に収集した情報の値を、cassandra.yaml ファイルの次のプロパティに追加します。
   • auto_bootstrap：この設定が存在し、falseに設定されている場合、trueに設定します。（この設定は、デフォルトのcassandra.yaml構成ファイルには含まれていません。）
   • cluster_name
   • シード・リスト
     警告: 新しいノードがシード・ノードの場合は、それ専用の- seedsリストにこのノードが含まれていないことを確認します。
10. ラックとデータ・センター構成を追加します。
    • クラスターでGossipingPropertyFileSnitch、Amazon EC2シングルリージョン・スニッチの構成、Amazon EC2マルチリージョン・スニッチの構成、またはGoogle Cloud Platformスニッチの構成が使用される場合：
      1. デッド・ノードのラックとデータ・センターの割り当てを、置き換えノードのcassandra-rackdc.propertiesファイルに追加します。
         注: また、デッド・ノードのIPアドレスのエントリーを削除しないでください。
      2. cassandra-topology.propertiesファイルを削除します。
    • クラスターでPropertyFileSnitchを使用している場合：
      1. 既存のノードから、cassandra-topology.propertiesファイルをコピーするか、設定をローカル・コピーに追加します。
      2. 新しいノードのIPアドレスとデッド・ノードのラックとデータ・センター割り当てを使用して、追加するエントリーを編集します。
11. 必須オプションを使用して新しいノードを起動します。
    パッケージ・インストール：

    1. 次のオプションを、jvm.optionsに追加します。

       -Dcassandra.replace_address_first_boot=address_of_dead_node

    2. アプリケーションで期待されるクラスターの整合性レベルがQUORUMまたはLOCAL_QUORUMの場合は、consistent_replaceオプションをjvm.options に追加します。その場合、QUORUM値またはLOCAL_QUORUM値のいずれかを使用することによって、置き換えノードのデータ整合性を保証してください。そうしないと、潜在的に整合性のないレプリカからノードがストリーミングされ、読み取りで古いデータが返される可能性があります。

       例を次に示します。

       -Ddse.consistent_replace=LOCAL_QUORUM

       ヒント: 整合性のある置き換え時にリペアを制御するその他のオプションは以下のとおりです。

       • consistent_replace.parallelism
       • consistent_replace.retries
       • consistent_replace.whitelist
    3. ノードを起動します。
    4. ノードがブートストラップした後、replace_address_first_bootおよびconsistent_replace（指定されている場合）をjvm.optionsから削除します。

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

    1. 次のパラメーターを起動コマンド・ラインに追加します。

       sudo bin/dse cassandra -Dcassandra.replace_address_first_boot=address_of_dead_node

    2. アプリケーションで期待されるクラスターの整合性レベルがQUORUMまたはLOCAL_QUORUMの場合は、replace_address_first_bootに加え、consistent_replaceパラメーターを追加します。その場合、QUORUM値またはLOCAL_QUORUM値のいずれかを使用することによって、置き換えノードのデータ整合性を保証してください。そうしないと、潜在的に整合性のないレプリカからノードがストリーミングされ、読み取りで古いデータが返される可能性があります。

       例を次に示します。

       sudo bin/dse cassandra -Dcassandra.replace_address_first_boot=address_of_dead_node -Ddse.consistent_replace=LOCAL_QUORUM

       ヒント: 整合性のある置き換え時にリペアを制御するその他のオプションは以下のとおりです。

       • consistent_replace.parallelism
       • consistent_replace.retries
       • consistent_replace.whitelist
12. nodetool statusを実行して、新しいノードが正常にブートストラップされていることを確認します。
    tarボールのパス：

    installation_location/resources/cassandra/bin

13. PropertyFileSnitchを使用する環境では、少なくとも72時間待ってから古いノードのIPアドレスを、cassandra-topology.properties ファイルから削除します。
    注意: これにより、古いノードの情報はゴシップから削除されます。プロパティ・ファイルから削除するのが早すぎると、問題が生じる場合があります。nodetool gossipinfoを使用して、ゴシップのステータスを確認します。ノードは、LEFTステータスが消えるまでゴシップの状態となります。

    注: cassandra-rackdc.propertiesファイルにはIP情報は含まれないため、GossipingPropertyFileSnitchなど、他のスニッチを使用する場合、このステップは不要です。