0

As a follow up of this Data Partition in Cassandra, I got the idea of the vNodes. Thanks to 'Simon Fontana Oscarsson'

When I try to explore the data partitioning using vNodes, I have few questions,

I try to observe the partition distribution in 2 node (./nodetool ring)

Two seed nodes (2 node)

172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -9207297847862311651                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -9185516104965672922                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -9135483708655236026                        
172.30.56.60  rack1       Up     Normal  102.77 KiB      100.00%             -9106737079237505681                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -9078521344187921602                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -9051897156173923903                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -9049800264451581717                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -9039572936575206977                        
172.30.56.60  rack1       Up     Normal  102.77 KiB      100.00%             -9019927187583981555                        
172.30.56.60  rack1       Up     Normal  102.77 KiB      100.00%             -9006071175095726599                        
172.30.56.60  rack1       Up     Normal  102.77 KiB      100.00%             -8995415525773810853                        
172.30.56.60  rack1       Up     Normal  102.77 KiB      100.00%             -8949342263103866059                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -8880432529087253108                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -8859265089807316498                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -8844286905987198633                        
172.30.56.61  rack1       Up     Normal  105.19 KiB      100.00%             -8832739468389117376

So as per my observation in two nodes, The Node 61 has the values from -9207297847862311651 to -9185516104965672922 as one range goes on...

NOTE : Partition range from '-9039572936575206977' to '-9019927187583981554' is currently handled by Node 61.

Now I am adding one more node to the cluster (not the seed node) and I ran ./nodetool ring,

Two seed nodes with one new node (3 node)

172.30.56.61  rack1       Up     Normal  104.12 KiB      64.73%              -9207297847862311651                        
172.30.56.61  rack1       Up     Normal  104.12 KiB      64.73%              -9185516104965672922                        
172.30.56.61  rack1       Up     Normal  104.12 KiB      64.73%              -9135483708655236026                        
172.30.56.60  rack1       Up     Normal  102.77 KiB      63.57%              -9106737079237505681                        
172.30.56.61  rack1       Up     Normal  104.12 KiB      64.73%              -9078521344187921602                        
172.30.56.61  rack1       Up     Normal  104.12 KiB      64.73%              -9051897156173923903                        
172.30.56.61  rack1       Up     Normal  104.12 KiB      64.73%              -9049800264451581717                        
172.30.56.61  rack1       Up     Normal  104.12 KiB      64.73%              -9039572936575206977                        
172.30.56.62  rack1       Up     Normal  103.7 KiB       71.70%              -9031848008695747480                        
172.30.56.62  rack1       Up     Normal  103.7 KiB       71.70%              -9028974600706382491                        
172.30.56.60  rack1       Up     Normal  102.77 KiB      63.57%              -9019927187583981555

Now I observed that same partition range is given to the new node Node 62, i.e, range from -9039572936575206977 to -9031848008695747480 is handled by Node 61 but -9031848008695747480 to -9019927187583981555 is handled by Node 62 (New node),

1) So does this mean that, adding a new node in the cluster will distribute the existing partition range?

2) Is there a way to observe the replicated partitions in Cassandra using any utility like nodetool?

3) I have 3 nodes with RF as 2, How to see the data's available in a node 62 alone?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Harry
  • 3,072
  • 6
  • 43
  • 100

1 Answers1

1

1) When adding a node Cassandra will start by choosing good ranges for the new node to take over. It will then create 256 new token ranges that are just portions of the already existing ones. This means the new node takes tokens from many nodes (instead of only one per RF when not using vnodes) in the cluster which makes streaming alot faster.

2 and 3) Does this answer your questions? determine node of a partition in Cassandra

Simon Fontana Oscarsson
  • 2,114
  • 1
  • 17
  • 20
  • Awesome for the point 2 and 3, But I am not convinced with Point 1, Example : You are saying that Node 1 will have the partition from 1 to 100 and Node 3 (newely added) node can have partition from 50 to 100, If so how the replication happens in it? – Harry Dec 04 '17 at 14:18
  • Also I can you explain the advantage of it? I didn't get your point of streaming :( – Harry Dec 04 '17 at 14:20
  • 1
    Node 1 will then stream it's data (with tokens 50-100) to Node 3. It still keeps the data but is not responsible for it, so it just takes space until you do 'nodetool cleanup'. Streaming: What I meant is that it's good to share many tokens with many nodes rather than one token with a few nodes. Imagine replacing a faulty node in a 30 node cluster. With vnodes your replacement node can stream from a lot of nodes at the same time, speeding up the process and spreading the increased load. Without RF 3 and vnodes there are only 2 nodes that hold that data. – Simon Fontana Oscarsson Dec 04 '17 at 15:03
  • please check this : https://stackoverflow.com/questions/50385262/cassandra-commit-log-size – Harry May 17 '18 at 07:21