In our tests we are adding 3000 keys into 3-node Riak db right after nodes
have joined.
For each key one node reads it and modifies it and another node does the
same but also deletes the key when it sees other change (key is no longer
needed). After all keys are processed our test framework checks if all keys
have been processed and deleted (bucket listing)

Now, since deletion is not instant in Riak I believe here is 3 second
delay, we are  doing that check in a loop listing and counting number of
keys in a bucket to check the progress. So far we've seen number of keys
going down, eventually reaching zero. Sometimes the number of keys remained
greater than zero, but after attempt to get a value we got null (Java
client) which indicates key has been deleted.
It's not perfect but it worked so far.

When we changed to ring size 512 things got bit hairy.
Our test fails and we have 24, 37 or 44  keys hanging around never going
down to zero, but rather going up and down between those numbers.

Test fails eventually. After that when I checked riak-admin transfer I
could see 96 partitions to be transfer on every node. BTW Active Transfer
section was showing nothing (I'm pretty sure there should be MB/s now)
In the end partitions pending for transfer hit zero few minuter after test
failed but that did not change anything.
Listing keys in the bucket via http client showed between 24-44 keys.
Manual reading via http client shows keys does not exist, and it looks like
read-repair removes it, but somehow number of keys cannot reach 0

When those keys will be removed? Do I need to get every key to trigger
read-repair?
Any suggestions what to change to improve that behaviour?

Bucket has allow_multi set to true, which I believe is necessary for that
kind of usage.
Riak db is in version 1.2.1 and backend LevelDB

Regards
Daniel
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to