Seeds are used in two different ways: 1) When joining the ring, the joining node knows NOTHING about the cluster, so it uses a seed list to discover the cluster. Once discovered, it saves the peers to disk, so subsequent starts it will find/reconnect to other nodes beyond just the explicitly listed seeds. This is the most important usage of seeds, and the one where if you fail to chose seeds in the right way you can end up in two distinct clusters. In your case, since node3 was probably in the ring and behaving, when nodes connected to node3 on their first start, they probably joined the ring fine.
2) During gossip, you can assume that each node gossips with 1 seed, 1 healthy node, and 1 dead node (if it exists). If you have a small, fixed seed list (such as 2 nodes per datacenter), you can guarantee that schema/topology changes are propagated very quickly, because all nodes will talk to those seeds right away. If you have randomized seeds, you may take quite some time for schema changes to propagate, but normal operation (reads/writes) will continue to be perfectly fine. In short: you’re probably fine, change the seeds in cassandra.yaml so they’re picked up on next start, but it’s probably not worth a rolling restart if everything’s behaving as intended. - Jeff On 7/25/15, 12:28 PM, "rock zhang" <r...@alohar.com> wrote: >Hi All, > >I have 6 node, most of them are using node1 as seed, but I just find out 2 >nodes are using node3 as seed, but everything looks fine. Does that mean seed >node does not have to be same on all nodes ? > >Thanks >Rock
smime.p7s
Description: S/MIME cryptographic signature
