NetworkTopologyを使用したカサンドラ移行後のデータの不一致

Question

私たちはカサンドラクラスタをAWS EC2上で実行しており、リング内に4つのノードがあります。環境全体をAzureに移行したかったのです。 既存のデータセンター（AWS EC2）で新しいデータセンター（Azure）を追加するプロセスを使用し、使用される戦略はNetworkTopologyであり、GossipingPropertyFileSnitchを使用しました。

新しいデータセンターが追加されたら、新しいデータセンターのすべてのノードで以下のコマンドを実行しました。 #nodetool rebuild - "データセンター名"

データは、既存のデータセンターのすべてのノードで約3 TBでした。 新しいデータセンターを再構築するのに約6〜7日かかりました。そして、system.logがそう言いました - すべてのセッションが完了しました。新しいデータセンターの各ノードでdbサイズを確認したところ、4つのノードすべてが既存のデータセンターよりもサイズが小さくなりました（それぞれ約75GB、つまり合計300GB）。

これは、新しいデータセンターのデータが既存のデータセンターと同じかどうかを確認する正しい方法であるかどうか教えてください。

Answer 1

データサイズは、データの不一致をチェックする正しい方法ではありません。

サイズは、様々な理由により異なる場合があり、そのうちのいくつかは、私が考えることができます：

1. 圧縮：あなたの圧密戦略は何ですか？あなたのデータはアプリケーションによって変更できませんでしたか？そうであれば、締め固めは理由ではなく、そうでない場合もあります。
2. フラッシュ：これらのサイズを確認する前にノードをフラッシュしましたか？そうでなければ、いくつかのデータはmemtablesにあるかもしれません。
3. キーキャッシュサイズなどは何ですか？どのようにデータサイズを正確に計算しましたか？それは単純な "デュ"データディレクトリまたは個々のテーブルファイルを一緒に追加されましたか？データディレクトリにはインデックスファイルや実際のデータがテーブルなどに格納されているため、これも正しい方法ではありません。

私の提案は、最初に各テーブルの行数を確認することです。両方のDCの設定がすべて同じであることを確認してください。その後、一貫性をチェックするスパークジョブを作成します（チェックサムまたは個々のフィールドを使用すると、チェックサムが高速になる場合があります）。スパークジョブが最適に実行され、データをシャッフルせずに実行されることを確認してください。数時間で実行でき、結果が得られるはずです。

注：これは私が実際に詳細を知ることなくできる最高です。