nodetool の修復がクラスターにどのように影響するか、またはクラスターのサイズが修復にどのように影響するかを理解するには、修復中に何が起こるかを理解する必要があります。修復には 2 つのフェーズがあり、最初のフェーズはデータのマークル ツリーを構築することです。2 つ目は、実際にレプリカにツリー間の違いを比較させ、必要に応じて相互にストリーミングさせることです。
この最初のフェーズは、修復を実行するノードのディスク上のほぼすべてのデータに影響するため、ディスク io に負荷がかかる可能性があります。リペアがディスク全体に影響するのを避ける簡単な方法の 1 つは、-pr フラグを使用することです。-pr を使用すると、修復が必要な disksize データの代わりに disksize/RF になります。ノードで修復を実行すると、これらの範囲のいずれかのレプリカを格納するすべてのノードにメッセージが送信され、マークル ツリーも構築されます。すべてのレプリカが同時にそれを行うため、データのその部分に対する応答が遅くなる可能性があるため、これは問題になる可能性があります。
修復操作が他のデータ センターにどのように影響するかを決定する要因は、レプリカ配置戦略の使用です。データ センター間で一貫性が必要になるため (EACH_QOURUM のケース)、ネットワーク トポロジ戦略のようなクロス DC レプリケーション戦略を使用することが不可欠です。修復の場合、これは、EACH_QUORUM の一貫性のケースがいくつかあるため、修復の実行中に自分自身をローカル DC に制限できないことを意味します。すべてのデータ センターのすべてのレプリカに影響する修復を回避するには、次のことを行う必要があります。これにより、データのスナップショットが作成されます (スナップショットは既存の sstable への単なるハードリンクであり、sstable が不変であるという事実を利用して、したがって、スナップショットは非常に安価になります）、スナップショットから順次修復されます。これは、特定のレプリカ セットに対して、一度に 1 つのレプリカのみが検証圧縮を実行することを意味し、動的スニッチが他のレプリカを介してアプリケーションのパフォーマンスを維持できるようにします。
今、私たちはあなたが持っている質問に答えることができます.
nodetool の修復の複雑さは、すべてのデータ センターのレプリカの数に比例して増加しますか? これを制限するには、レプリケーション戦略を動的スニッチでラップし、修復中に -snapshot オプションを渡します。
それとも、nodetool の修復の複雑さは、現在のデータ センター内のレプリカの数とデータ センターの数の組み合わせに比例して増加しますか? 漠然と、このモデルは現在のデータセンターの個々のノードのそれぞれとデータを同期する可能性がありますが、他のデータセンターのレプリカに対して EACH_QUORUM のような操作を行います。上記のアプローチを使用すると、レプリカの数に応じて実行時間の点で複雑さが増します。これは、上記のアプローチでは一度に 1 つのレプリカで順次修復が行われるためです。
クラスターをスケーリングするには、既存のデータ センターにノードを追加するのと、全体として一定数のレプリカを想定して新しいデータ センターを追加するのとのどちらが良いですか? この質問は、nodetool 修復パフォーマンスのコンテキストで行います。nodetool repair の観点から見ると、上記のアプローチを採用しても、これは何の違いもありません。レプリカの総数に依存するためです。
また、nodetool を使用した修復の目的は、削除が戻らないようにすることです。定期的な修復頻度の厳しい要件は、gc_grace_seconds の値です。データの削除や上書きがほとんどないシステムでは、ディスク容量への影響を最小限に抑えて gc_grace の値を上げることができます。これにより、nodetool ユーティリティを使用して修復操作をスケジュールする間隔を広げることができます。頻繁な修復を回避するための推奨される方法の 1 つは、設計によりレコードを不変性にすることです。数十のデータセンターで実行する必要があり、そうでなければ運用はすでに苦痛になるため、これは重要かもしれません.