3

VM 環境でクラスターにノードを追加するときの initial_token の衝突に関する既知の問題はありますか?

VM にセットアップされた 4 ノード クラスターに取り組んでいます。クラスターにノードを追加しようとすると、問題が発生します。

cassandra.yaml ファイルでは、initial_token は空白のままです。> 1.0 cassandra を実行しているため、auto_bootstrap はデフォルトで true になっているはずです。

クラスター内の各ノードには、起動時に初期トークンを割り当てる必要があると理解しています。

これは、現在私たちが見ているものではありません。各ノードの initial_token の値を手動で設定したくありません (動的であるという目標を無効にするようなものです..) また、パーティショナーをランダムに設定しました: パーティショナー: org.apache.cassandra.dht.RandomPartitioner

以下に、私たちが従う手順と結果を概説しました。ここで何が欠けているかについて誰かアドバイスしてもらえますか?

私たちが取っている詳細な手順は次のとおりです。

1) すべての cassandra インスタンスを強制終了し、各ノードでデータとコミット ログ ファイルを削除します。

2) スタートアップ シード ノード (SSSS)

元気に起動します。

3) nodetool -h WWWW ring を実行し、以下を参照してください。

Address         DC          Rack        Status State   Load            Effective-Ownership Token
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463

4) XXXXスタートアップ

 INFO [GossipStage:1] 2012-11-29 21:16:02,194 Gossiper.java (line 850) Node /X.X.X.X is now part of the cluster
 INFO [GossipStage:1] 2012-11-29 21:16:02,194 Gossiper.java (line 816) InetAddress /X.X.X.X is now UP
 INFO [GossipStage:1] 2012-11-29 21:16:02,195 StorageService.java (line 1138) Nodes /X.X.X.X and /Y.Y.Y.Y have the same token 113436792799830839333714191906879955254.  /X.X.X.X is the new owner
 WARN [GossipStage:1] 2012-11-29 21:16:02,195 TokenMetadata.java (line 160) Token 113436792799830839333714191906879955254 changing ownership from /Y.Y.Y.Y to /X.X.X.X

5) nodetool -h WWWW ring を実行し、以下を参照してください。

Address         DC          Rack        Status State   Load            Effective-Ownership Token
                                                                                           113436792799830839333714191906879955254
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
W.W.W.W         datacenter1 rack1       Up     Normal  123.87 KB       100.00%             113436792799830839333714191906879955254

6) YYYY スタートアップ

 INFO [GossipStage:1] 2012-11-29 21:17:36,458 Gossiper.java (line 850) Node /Y.Y.Y.Y is now part of the cluster
 INFO [GossipStage:1] 2012-11-29 21:17:36,459 Gossiper.java (line 816) InetAddress /Y.Y.Y.Y is now UP
 INFO [GossipStage:1] 2012-11-29 21:17:36,459 StorageService.java (line 1138) Nodes /Y.Y.Y.Y and /X.X.X.X have the same token 113436792799830839333714191906879955254.  /Y.Y.Y.Y is the new owner
 WARN [GossipStage:1] 2012-11-29 21:17:36,459 TokenMetadata.java (line 160) Token 113436792799830839333714191906879955254 changing ownership from /X.X.X.X to /Y.Y.Y.Y

7) nodetool -h WWWW ring を実行し、以下を参照してください。

Address         DC          Rack        Status State   Load            Effective-Ownership Token
                                                                                           113436792799830839333714191906879955254
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
Y.Y.Y.Y         datacenter1 rack1       Up     Normal  123.87 KB       100.00%             113436792799830839333714191906879955254

8) ZZZZ 起動

 INFO [GossipStage:1] 2012-11-30 04:52:28,590 Gossiper.java (line 850) Node /Z.Z.Z.Z is now part of the cluster
 INFO [GossipStage:1] 2012-11-30 04:52:28,591 Gossiper.java (line 816) InetAddress /Z.Z.Z.Z is now UP
 INFO [GossipStage:1] 2012-11-30 04:52:28,591 StorageService.java (line 1138) Nodes /Z.Z.Z.Z and /Y.Y.Y.Y have the same token 113436792799830839333714191906879955254.  /Z.Z.Z.Z is the new owner
 WARN [GossipStage:1] 2012-11-30 04:52:28,592 TokenMetadata.java (line 160) Token 113436792799830839333714191906879955254 changing ownership from /Y.Y.Y.Y to /Z.Z.Z.Z

9) nodetool -h WWWW ring を実行し、以下を参照してください。

Address         DC          Rack        Status State   Load            Effective-Ownership Token
                                                                                           113436792799830839333714191906879955254
W.W.W.W         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
Z.Z.Z.Z         datacenter1 rack1       Up     Normal  123.87 KB       100.00%             113436792799830839333714191906879955254

前もって感謝します。

4

2 に答える 2

3

ノードが、起動時に使用されていた過去のクラスター情報を保持していることは明らかです。クラスターに関するデータを含む LocationInfo ディレクトリを必ず削除してください。非常に奇妙なトークン レイアウトを使用しているため (たとえば、0 トークンはどこにあるのでしょうか?)、適切な所有権が必要な場合は、トークンを再割り当てする必要があります。

トークンの割り当てがどのように機能するかを説明するのに役立つかもしれないので、これについても説明しましょう。真新しいクラスターでは、最初のノードにはデフォルトでトークン 0 が割り当てられ、所有権は 100% になります。次のノードのトークンを指定しない場合、Cassandra は元のノードが下位 50% を所有し、新しいノードが上位 50% を所有するようにトークンを計算します。

ノード 3 を追加すると、1 番目と 2 番目の間にトークンが挿入されるため、実際には所有権が 25%、25%、50% のようになります。これは非常に重要です。なぜなら、ここで学ぶべき教訓は、リングのバランスを取るために Cassandra がそれ自体でトークンを再割り当てすることは決してないということだからです。所有権を適切にバランスさせたい場合は、独自のトークンを割り当てる必要があります。これは難しいことではなく、実際にこれを行うためのユーティリティが提供されています。

そのため、Cassandra の最初のブートストラップ プロセスは動的ではありますが、望ましいリング バランスが得られない場合があります。希望する結果が得られるようにするための介入なしに、新しいノードを勝手に参加させることはできません。そうしないと、質問で提示したシナリオになってしまいます。

于 2012-12-05T14:58:45.813 に答える
2

これは、この問題を解決するために私がしたことです：

  1. Cassandra サービスを停止する
  2. auto_bootstrap: falseシード ノードに設定します。
  3. 空のデータおよび commitlog ディレクトリ: sudo rm -rf /var/lib/cassandra/data/* sudo rm -rf /var/lib/cassandra/commitlog/*
  4. そして、サービスを再起動します

これを Cassandra 3.7 でテストしました。

于 2016-08-30T08:11:34.900 に答える