[
https://issues.apache.org/jira/browse/CASSANDRA-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6289:
--------------------------------------
Attachment: 6289-v2.txt
I think the real problem is that displaying replica count derived from
sum(ownership) is fundamentally broken. Consider using SimpleStrategy instead
of NTS -- you'll just get nonsense.
I think the right solution is to rip this out instead of trying to compensate
for one inaccuracy by applying more on an ad hoc basis until it looks right in
some cases. But, I don't want to break anyone parsing nodetool output in
1.2.x. Patch attached for 2.0.
> Murmur3Partitioner doesn't yield proper ownership calculation
> -------------------------------------------------------------
>
> Key: CASSANDRA-6289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6289
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Reporter: Jackson Chung
> Assignee: Mikhail Stepura
> Priority: Minor
> Fix For: 1.2.12
>
> Attachments: 6289-v2.txt, cassandra-1.2-6289.patch
>
>
> In a new 1.2 install with Murmur3 as default, I setup a test cluster with
> N=RF=3 for the cluster size and RF for a keyspace
> but when I look at the ring output (with the keyspace name), to my surprise
> it shows RF=2.
> Further investigate shows the "total replica" is an addition of the float
> value from the effectiveOwnership. But that results in < 1 for the setup:
> {panel}
> #bean is set to org.apache.cassandra.db:type=StorageService
> $>run effectiveOwnership Keyspace1
> #calling operation effectiveOwnership of mbean
> org.apache.cassandra.db:type=StorageService
> #operation returns:
> \{
> /127.0.0.1 = 0.9999989;
> /127.0.0.2 = 0.9999989;
> /127.0.0.3 = 0.9999989;
> \}
> {panel}
> {panel}
> $ ./bin/nodetool -h 0 -p 7100 ring Keyspace1
> Datacenter: datacenter1
> ==========
> Replicas: 2
> Address Rack Status State Load Owns
> Token
>
> 3074457345618258602
> 127.0.0.1 rack1 Up Normal 1.02 GB 100.00%
> -9223372036854775808
> 127.0.0.2 rack1 Up Normal 996.38 MB 100.00%
> -3074457345618258603
> 127.0.0.3 rack1 Up Normal 980.55 MB 100.00%
> 3074457345618258602
> {panel}
> {panel}
> Keyspace: Keyspace1:
> Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
> Durable Writes: true
> Options: [replication_factor:3]
> {panel}
> The println would simply class the float value to int, so i guess that's
> round down.
> When using RandomPartitioner, the effectiveOwnership will return 1.0
> So I guess the real question is, is the Murmur3 calculation correct? Or is it
> losing precision? If it is correct, then I guess we need to force the float
> -> int to round up? (is that even the right thing to do?)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
