Repair Service（リペア・サービス）の概要

Repair Service（リペア・サービス）のサマリー

Repair Service（リペア・サービス）は、DSEクラスターのリペア・プロセスを自動化します。サービスが処理するリペアには、サブ範囲とインクリメンタルの2つのタイプがあります。

リペアという用語はあまりふさわしくありません。Repair Service（リペア・サービス）が実行するリペアは、主にノードやそのレプリカ間で最新データを同期します。これには、ファイル・システム・レベルで発生した破損データのリペアも含まれます。Repair Service（リペア・サービス）は、サブ範囲リペアとインクリメンタル・リペアをどちらも実行できます。デフォルトでは、Repair Service（リペア・サービス）はほとんどのテーブルに対してサブ範囲リペアを実行し、特定のテーブルに対しては、インクリメンタル・リペアを実行するように構成できます。

サブ範囲リペアでは、ノードが担当しているデータ部分がリペアされます。Repair Service（リペア・サービス）のサブ範囲リペアは、nodetool repairコマンドで-stオプションと-etオプションを指定することに似ていますが、サブ範囲の開始トークンと終了トークンを自動的に判断して最適化するのはRepair Service（リペア・サービス）のみです。サブ範囲リペアの主な利点は、過剰なストリーミングを回避しながら、リペア対象をより正確に特定できることです。

インクリメンタル・リペアでは、インクリメンタル・リペア用に予約され、構成されているテーブルのまだリペアされていないデータのみがリペアされます。

サブ範囲リペアは除外（オプト・アウト）ベースで動作し、特定のキースペースやテーブルを除外できます。サブ範囲リペアから除外されるテーブルには、OpsCenterで予約されているテーブルと管理者が構成したテーブルが含まれます。インクリメンタル・リペアは包含（オプト・イン）ベースで動作します。インクリメンタル・リペアの対象として指定されているキースペースとテーブルのみがインクリメンタル・リペアで処理されます。インクリメンタル・リペアの対象となっているテーブルには、OpsCenterの組み込みテーブルと管理者が構成したテーブルが含まれます。

データが比較的静的な場合は、これらのテーブルまたはデータ・センターに対してインクリメンタル・リペアを構成します。データが動的で常に変化している場合は、サブ範囲リペアを使用し、環境に合わせてキースペースとテーブルを除外します。

サブ範囲リペアとインクリメンタル・リペアが重複することはありません。キースペースとテーブルは、サブ範囲リペアとインクリメンタル・リペアのどちらかでリペアされます。サブ範囲リペアとインクリメンタル・リペアは、テーブル・レベルで互いに排他的です。Repair Service（リペア・サービス）は、両方のタイプのリペアを同時に実行します。各リペア・タイプには独自のタイムラインがあり、リペア・ステータス・サマリーのそれぞれ対応するサブ範囲およびインクリメンタル進行状況バーで追跡されます。

パラメーター

time_to_completionパラメーターは、クラスター全体を一度にリペアするために要する最大時間です。

Repair Service（リペア・サービス）は複数のサブ範囲リペアを並列処理で実行できますが、指定されている時間内に完了するために必要な最小数を実行します。Repair Service（リペア・サービス）は常に、単一のレプリカ・セット内で複数のリペアを実行することを回避します。複数のレプリカ・セットでリペアが重複することはありません。

残りのリペア時間の推定

Repair Service（リペア・サービス）で、スループットが原因で割り当てられている完了までの時間内にリペア・サイクルを完了できないことが予想される場合、警告メッセージと、リペア・サイクルが完了するまでの新たな残り推定時間が表示されます。Repair Service（リペア・サービス）は、構成されている完了までの時間を調整しません。進行中のリペアを停止することなく完了までの変更後の推定時間を報告します。

Repair Service（リペア・サービス）が、構成されているtime_to_completion内にリペア・サイクルを完了できないと予想した場合は、OpsCenterのイベント・ログにアラートがトリガーされます。アラートは、opscenterd.logのほか、OpsCenter UIの［Activity］セクションの［Event Log］にも表示されます。電子メール・アラートまたはURL送信アラート通知が構成されている場合は、アラート通知が電子メールで送信されるか、URLが送信されます。

error_logging_window構成プロパティは、Repair Service（リペア・サービス）が時間内にリペアを完了できないことを引き続き予想している場合にメッセージをログに記録する間隔と、アラートを発行する間隔を制御します。

並列およびシーケンシャル検証コンパクション処理

Repair Service（リペア・サービス）は、デフォルトではシーケンシャルではなく、並列処理で検証コンパクションを実行します。これは、シーケンシャル処理には非常に時間がかかるためです。snapshot_override設定は、サブ範囲リペアとインクリメンタル・リペアの両方で検証コンパクションが並列処理されるか、シーケンシャルに処理されるかを制御します。「検証コンパクションをシーケンシャルに実行する」を参照してください。

再起動の間隔

Repair Service（リペア・サービス）は、トポロジーまたはスキーマが変更されたことを検出すると一時停止し、一定期間後に再起動します。再起動の間隔はrestart_period構成オプションで制御され、デフォルトは300秒（5分）です。一時停止中、Repair Service（リペア・サービス）はこの期間を利用して、クラスターを再アクティブ化できるまで定期的にクラスターの状態をチェックします。

Repair Service（リペア・サービス）が実行されない状態

単一ノードのクラスターはリペアの対象となりません。リペアではノードのレプリカの整合性を保つため、リペア・プロセス中にMerkleツリーを交換するために少なくとも2つのノードが必要になります。

環境の変更時のRepair Service（リペア・サービス）の動作

以下の各セクションでは、トポロジーの変更、ノードの停止、OpsCenterの再起動など、環境の変更時のRepair Service（リペア・サービス）の動作について詳しく説明します。

クラスター・トポロジーの変更

Repair Service（リペア・サービス）は、クラスターのトポロジーの変更を直ちに認識します。クラスター・トポロジーが変更されると、Repair Service（リペア・サービス）は現在のリペア・サイクルを停止し、リングが安定するまで待機してから新しいサイクルを再開します。リペアを再開する前に、Repair Service（リペア・サービス）はデフォルトで30秒ごとにクラスターの状態をチェックします。クラスターが安定した後は、opscenterdが次に再起動されるまで、クラスターの安定化のチェックは停止されます。クラスターの安定化をチェックする間隔を構成するには、cluster_stabilization_periodオプションを使用します。

スキーマの変更

スキーマが変更されると、Repair Service（リペア・サービス）はデフォルトで5分間一時停止してから再起動し、新しいキースペースまたはテーブルのリペアを直ちに開始します。スキーマの変更には、キースペースまたはテーブルの追加、変更、削除が含まれます。

ノードまたはレプリカのダウン

対象範囲のレプリカ・セットのノードのいずれかがダウンしている場合、リペアを実行することはできません。ラックまたはデータ・センター全体がダウンしている場合は、そのクラスターでリペア操作を正常に実行できない可能性があります。1つ以上のノードがダウンしている場合、Repair Service（リペア・サービス）はダウンしているノードの影響を受けていない範囲とキースペースに対してリペアを引き続き実行します。

実行可能なリペア操作がなくなると、Repair Service（リペア・サービス）は10秒間待機してから再びチェックします。Repair Service（リペア・サービス）は最大でmax_down_node_retryオプションの構成値までチェックを繰り返します。このオプションはデフォルトでcassandra.yamlのmax_hint_window_in_msプロパティに基づいて3時間に設定されており、その後新しいサイクルを開始します。ダウンしているノードのmax_hint_window_in_msを超過した後、そのノードの復元プロセスでは、ヒントのリプレイに従うのではなく、リビルドを行います。したがって、Repair Service（リペア・サービス）では新しいサイクルを開始して可能な範囲のリペアを続行するため、ダウンしているノードでブロックされることはありません。

opscenterdの再起動時に保持されているリペアの状態

各保持期間（デフォルトでは1時間）が終わると、Repair Service（リペア・サービス）の現在の状態は永続ディレクトリーの場所にあるopscenterdサーバーにローカルに保持されます。保持期間の間隔は、persist_periodオプションを使用して構成できます。永続ディレクトリーの場所は、persist_directoryオプションを使用して構成できます。opscenterdが再起動されると、Repair Service（リペア・サービス）は保持されていた状態情報に基づいて、処理が停止した時点から再開します。

障害発生時のRepair Service（リペア・サービス）の連続性の詳細については、「フェイルオーバーの影響」を参照してください。