I've been digging into this and worked was able to reproduce something, not
sure if it's a fault and I can't work on it any more tonight.
To reproduce:
- 2 node cluster on my mac book
- set the tokens as if they were nodes 3 and 4 in a 4 node cluster, e.g. node 1
with 85070591730234615865843651857942052864 and node 2
127605887595351923798765477786913079296
- set cassandra-topology.properties to put the nodes in DC1 on RAC1 and RAC2
- create a keyspace using NTS and strategy_options = [{DC1:1}]
Inserted 10 rows they were distributed as
- node 1 - 9 rows
- node 2 - 1 row
I *think* the problem has to do with TokenMetadata.firstTokenIndex(). It often
says the closest token to a key is the node 1 because in effect...
- node 1 is responsible for 0 to 85070591730234615865843651857942052864
- node 2 is responsible for 85070591730234615865843651857942052864 to
127605887595351923798765477786913079296
- AND node 1 does the wrap around from 127605887595351923798765477786913079296
to 0 as keys that would insert past the last token in the ring array wrap to 0
because insertMin is false.
Thoughts ?
Aaron
On 3 May 2011, at 10:29, Eric tamme wrote:
> On Mon, May 2, 2011 at 5:59 PM, aaron morton <aa...@thelastpickle.com> wrote:
>> My bad, I missed the way TokenMetadata.ringIterator() and firstTokenIndex()
>> work.
>>
>> Eric, can you show the output from nodetool ring ?
>>
>>
>
> Sorry if the previous paste was way to unformatted, here is a
> pastie.org link with nicer formatting of nodetool ring output than
> plain text email allows.
>
> http://pastie.org/private/50khpakpffjhsmgf66oetg
