NodeSyncについて
オーバーヘッドが少なく、一貫したパフォーマンスを提供し、DataStaxクラスターでリペア操作を実行するための手動作業を事実上無くした、連続的なバックグラウンド・リペアを容易に使用できます。
NodeSyncは、オーバーヘッドが少なく、一貫したパフォーマンスを提供し、DataStaxクラスターでリペア操作を実行するための手動作業を事実上無くした、連続的なバックグラウンド・リペアを容易に使用できます。
- すべてのレプリカでデータが同期していることを継続的に検証
- 常に実行しているが、クラスターのパフォーマンスへの影響は少ない
- 完全自動で、手動介入は不要
- アンチエントロピー・リペアを完全に置き換える
NodeSyncサービス
デフォルトでは、各ノードはNodeSyncサービスを実行します。何かを検証するまで、サービスはアイドル状態です。NodeSyncはテーブルごとに有効にできます。このサービスは、NodeSyncが有効にされているテーブルのローカル・データ範囲を継続的に検証し、不整合が見つかった場合はリペアします。このローカル・データ範囲は小さなセグメントに分割され、検証保存ポイントとして機能します。セグメントは、テーブルごとのデッドラインの目標を満たすために優先順位付けされます。
セグメント
セグメントは、テーブルの小さなローカル・トークン範囲です。NodeSyncは、ある一定回数（深さ）、ローカル範囲を繰り返し半分に分割してセグメントを作成します。深さは、データを均等に分配する想定で、テーブルの合計サイズを使用して計算されます。通常、セグメントは200 MBまで対応しています。トークン範囲は単一のパーティションより小さくなることはないため、極めて大きなパーティションの場合、構成したサイズよりもセグメントが大きくなってしまう可能性があります。
検証プロセスとステータス
検証用にセグメントが選択された後、NodeSyncは、すべてのレプリカから、対象のデータ全体を読み取り（ページングを使用して）、不整合をチェックし、必要に応じてリペアします。ノードがセグメントを検証するときに、他のノードによる作業の重複を避けるために、そのセグメントをシステム・テーブルに「ロック」します。これは競合のないロックではありません。重複した作業の可能性があり、真の分散ロックの複雑さとコストを節約します。
system_distributed.nodesync_statusテーブル内の完了に保存されます。このデータは、失敗の再開、優先順位付け、セグメントのロック用として内部で使用されたり、ツールで使用されます。これは、直接読み取れるものではありません。 - 検証ステータスは次のようになります。
successful: 応答したレプリカすべてと不整合すべて（見つかった場合）は、適切にリペアされました。full_in_sync: レプリカはすべて、既に同期されていました。full_repaired: レプリカのうちいくつかは、リペアされていました。
unsuccessful: 応答しなかったレプリカがあるか、不整合レプリカにおけるリペアができませんでした。partial_in_sync: すべてのレプリカが応答したわけではありませんが、応答があったものはすべて同期されていました。partial_repaired: すべてのレプリカが応答したわけではありません。中には、リペアされていたものもあります。uncompleted: 最大1つのノードが、利用可能であった/応答がありました。検証は行われませんでした。failed: 予期せぬエラーがいくつか発生しました。（ノードのログをご確認ください）注: 大きなセグメントの検証が中断された場合、冗長な作業の量を増やします。
制限事項
- NodeSyncは読み取りリペア・パスによって異なるため、デバッグ/調整では、従来のリペアを理解しておくことは、ほとんど役に立ちません。
- リモートDCには特別な最適化というものは存在しません。特に質の悪いWANリンクでは、パフォーマンスが低下する場合があります。
- 全体では、NodeSyncにおけるCPU使用率は、従来のリペアを上回る可能性があります。
- NodeSyncでは、構成済みのレートに届くように内部調整だけを行います。オペレータは、構成されているこのスループットが、gc_grace_secondsの役割を果たす上で十分であることと、ハードウェアによって達成可能であることを確認する必要があります。
repairコマンドが拒否されます。