サブ範囲リペアの概要
サブ範囲リペアの動作と使用できる構成オプションのサマリー。
サブ範囲リペア
サブ範囲リペアは、ノードが担当しているデータ部分をリペアします。別に実行されているインクリメンタル・リペアも含め、クラスター全体がリペアされると、Repair Service(リペア・サービス)は、リペアするサブ範囲のリストを再計算し、最初から繰り返します。クラスター全体を1回リペアすることを「リペア・サイクル」と呼びます。
キースペースとテーブルの除外
デフォルトのシステム・キースペースや特定のロールアップ・テーブルなどのほかに、サブ範囲リペアが無視するキースペースや特定のテーブルを指定します。「サブ範囲リペアからキースペースまたはテーブルを除外する」を参照してください。
タスクの優先順位付け
prioritization_page_size
オプションを使用すると、影響の少ないリペアを選択するときにRepair Service(リペア・サービス)が検討する可能なリペア・タスクの数が制限されます。ページ・サイズを大きくするとRepair Service(リペア・サービス)のCPU使用量が増えますが、クラスターに対するリペアのディスパッチをより最適な方法で実行できます。prioritization_page_size
はエキスパート・オプションであり、DataStaxサポートのガイダンスを受けずに変更しないでください。オフライン分割
オフライン分割とは、ノードがダウンしているか使用できない場合にRepair Service(リペア・サービス)がオフラインでタスクを生成する(サブ範囲リペアの分割を特定する)ことです。
各エージェントはリペアする各キースペースの最適なサブ範囲分割セットを決定するために必要なデータをノードから取得できるため、理想的には、サブ範囲リペアの計画中にOpsCenterデーモンのRepair Service(リペア・サービス)がクラスター内の各OpsCenterエージェントからトークン・サブ範囲分割を取得します。ただし、エージェントまたはノードのいずれかがオフラインまたは使用できない状態にある場合、Repair Service(リペア・サービス)はそのノードのトークン範囲を分割し直します。OpsCenterデーモンは、使用できないノードのトークン範囲に属するパーティションの数とサイズに関する情報にアクセスできないため、これでは最適な分割は行えません。
offline_splits
オプションは、ノードのプライマリ範囲を分割する際のキースペースごとのサブ範囲の数を制御します。各サブ範囲の目標は、キースペースごとのパーティション数を約32,000以下に抑えることです。ノード間で必要以上にデータをストリーミングせずに1回でリペアできる範囲内の最大パーティション数が32,000なので、32,000のパーティションを含むサブ範囲をリペアするのが最適です。
offline_splits
オプションのデフォルトは256です。ノード数が少ないクラスターであれば、デフォルトで十分です。ノードがより高密度のクラスターでは、デフォルト値を大きくすると効果的です。system.size_estimates
テーブルは5分ごとに再生成され、これによって、各ノードのプライマリ範囲に含まれているキースペースとテーブルごとのパーティションの数がある程度わかります。
オフライン分割の構成オプションと関連するオプションは、エキスパートレベルのオプションとみなされます。DataStaxサポートのガイダンスを受けずに調整しないでください。
Repair Service(リペア・サービス)ログにより、ノードにオフライン分割を使用する必要があったかどうかがわかります。
サブ範囲リペア時間のスロットル
Repair Service(リペア・サービス)は、現在のリペア・サイクルが完了までの時間で指定された期限より大幅に早く終了すると予想される場合、サブ範囲リペアを自動的にスロットルします。
time_to_completion_target_percentage
構成オプションは、サブ範囲リペア・プロセスの間隔と速度を制御します。スロットルは、クラスターの過負荷を防ぐために必要に応じてリペアを遅延させるか、パラレル・リペア・プロセスを低減しながら、[Time to completion]の値で指定されている特定の時間枠内でリペア・サイクルを完了します。リペアを完了する目標率のデフォルト値は65%です。
一部のリペア構成オプションは百分率で調節されるため、高度なリペア・オプションを慎重に構成することで、さまざまな実稼働環境のリペア・パフォーマンスを最適化し、不適切な構成が引き起こす問題を回避できます。大部分のデフォルト設定は、DataStaxサポート・スタッフが指示する場合を除き、通常は調整する必要がありません。
Repair Service(リペア・サービス)構成に問題がある場合、Best Practice Service(ベスト・プラクティス・サービス)の「Repair Service(リペア・サービス)が正しく構成されていない」ルールが不合格になり、正しく構成されていないオプションに関するガイダンスが表示されます(ルールがオフになっている場合を除く)。
time_to_completion_percentage
スロットルを使用していない場合にのみ、max_parallel_repairs
を手動で調整し、min_repair_time
とその他の高度なオプションやエキスパート・オプションの変更を行うことを推奨しています。「サブ範囲リペアのスロットルの調整または無効化」を参照してください。詳細については、「サブ範囲リペアのスロットルの調整または無効化」を参照してください。
パラレル・リペア数の計算
Repair Service(リペア・サービス)は、最近行ったリペアのスループットの平均値を使用して平均スループットを計算します。平均スループットは、現在のサイクルでリペアを完了するのに必要なパラレル・リペアの数を動的に特定するために使用されます。num_recent_throughputs
オプションは、平均スループットの計算に使用する最近のスループットの最大値を特定します。デフォルト値は500です。パラレル・リペア数の計算は、計算を始める前の対応する最小スループット値にも依存します。min_throughput
オプションは、パラレル・リペア数を特定するときに考慮される特定のリペア・タスクに必要なスループットを表します。デフォルト値は512バイト/秒です。詳細については、「パラレル・サブ範囲リペアの最大値の設定」を参照してください。
最大保留リペア数
新しいサブ範囲リペアを実行する前に、Repair Service(リペア・サービス)は実行中または実行待機中のリペアの数をチェックします。構成されている最大保留リペア数のしきい値を超えると、既にスワンプ状態にあるノードに負荷をかけないために、当分の間、そのノードのリペアはスキップされます。リペア・タスクは、後でリトライするために保留中のリペア・タスクのキューの最後に移動され、アラートが発行されます。
サブ範囲リペアのステータス
[Repair Status]タブにサブ範囲リペアの進行状況、統計、および詳細が表示されます。