リペア・ストラテジの変更

定期的なリペアに使用する方法をインクリメンタル・リペアまたはフル・リペアから変更します。

定期的なリペアに使用する方法をインクリメンタル・リペアまたはフル・リペアから変更します。データベースのメンテナンスには、アンチエントロピー・リペアを使用したSSTableのリペアが必要です。ノードでのすべてのSSTableのフル・リペアには多くの時間がかかり、リソース使用量も多くなります。インクリメンタル・リペアでは、リペア済みとマークされているSSTableはスキップされるため、処理時間およびリソース使用量は少なくなります。

フル・リペアへの移行

インクリメンタル・リペアからフル・リペアに切り替える前に、リペア・ステータスを削除します。

インクリメンタル・リペアでは、データをリペア済みSSTableと未リペアSSTableに分離し、データ状態にメタデータでマークを付けます。フル・リペアでは、データはまとめられたまま維持され、リペア・ステータス・フラグは使用されません。インクリメンタル・リペアからフル・リペアに切り替える前に、ステータスを削除します。

nodetool mark_unrepaired keyspace_name [table_name]

インクリメンタル・リペアへの移行

インクリメンタル・リペアの使用を開始するには、各ノードのSSTableを移行します。

インクリメンタル・リペアの使用を開始するには、各ノードのSSTableを移行します。インクリメンタル・リペアは、既にリペア済みのマークが付いているSSTableをスキップします。これらの手順により、リペア・ストラテジをフルからインクリメンタルに変更する際、データの整合性を確保します。
警告: DataStaxでは、フル・リペアを使用することを推奨しています。インクリメンタル・リペアにより、パフォーマンスの問題が生じることがあります。「CASSANDRA-9143」を参照してください。

始める前に

RHELおよびDebianへのインストールでは、以下の手順に進む前にツール・パッケージをインストールしてください。

重要: この手順を開始する前に、データベースがすべてのSSTableを再コンパクションするため、最初のシステム全体のフル・リペア(3)には時間がかかる場合がありますのでご注意ください。このプロセスの混乱を少なく抑えるために、一度に1ノードずつクラスターをインクリメンタル・リペアに移行します。

手順

ターミナル内:
  1. ノードの自動コンパクションを無効にします。
    nodetool disableautocompaction

    tarボールおよびInstaller-No Servicesのパス: install_directory/bin

    注: パラメーターなしで、nodetool disableautocompactionを実行すると、すべてのキースペースの自動コンパクションが無効になります。
  2. フル・リペア(3)を実行する前に、/var/lib/cassandra/dataにあるノードSSTableをリストアップします。コマンドを実行して、5repairedAtフラグを設定する上で、このリストが必要になります。
    データディレクトリーには、各キースペース用のサブディレクトリーがあります。各サブディレクトリーには、各SSTable用のファイル一式が入っています。SSTableデータを含むファイル名には、以下のような形式があります。
    <version_code>-<generation>-<format>-Data.db
  3. デフォルトのシーケンシャル・リペアを一度に1ノードずつすべて実行します。
    nodetool repair
    tarボールおよびInstaller-No Servicesのパス: install_directory/bin

    パラメーターなしで、nodetool repairを実行すると、ノードのすべてのSSTableのシーケンシャル・リペアを実行し、非常に時間がかかることがあります。

  4. ノードを停止します
  5. 2で作成したリストを使用して、sstablerepairedsetを使用している各SSTableのrepairedAtフラグを--is-repairedに設定します。

    各SSTable用に、repairedAtをリペア済みに設定しない限り、リペア・プロセスでは既存のSSTableは変更されず、追って実行されるインクリメンタル・リペア・プロセスはこれらのSSTableを処理しません。

    • 以下で1つのSSTableをマークします。
      sudo sstablerepairedset --really-set --is-repaired SSTable-example-Data.db
    • バッチ処理する場合、SSTable名のテキスト・ファイルを使用します。
      sudo sstablerepairedset --really-set --is-repaired -f SSTable-names.txt
    tarボールおよびInstaller-No Servicesのパス:
    installation_location/resources/cassandra/tools/bin
    注: repairedAtフラグの値は、前回リペアのタイムスタンプです。sstablerepairedsetコマンドには、現在の日時が適用されます。repairedAtフラグの値を確認するには、次を使用します。
    sstablemetadata example-keyspace-SSTable-example-Data.db | grep "Repaired at"
  6. ノードを再起動します

次のタスク

すべてのノードを移行したら、-incオプション付きのnodetool repairを使用してインクリメンタル・リペアを実行できます。