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

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

Repair Service（リペア・サービス）は、クラスターのトポロジーの変更を直ちに認識します。クラスター・トポロジーが変更されると、Repair Service（リペア・サービス）は現在のリペア・サイクルを停止し、リングが安定するまで待機してから新しいサイクルを再開します。再起動の間隔はrestart_period構成オプションで制御され、デフォルトは300秒（5分）です。一時停止中、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（リペア・サービス）の連続性の詳細については、「フェイルオーバーの影響」を参照してください。