Any idea what happened? We have had to remove the riak db and started
from scratch to get rid of the ghost keys...

On Thu, 7 Mar 2013 11:35:12 +0100
Simon Effenberg <[email protected]> wrote:

> Now we see only 3 occurrences of the keys. So maybe the reducing of the
> n_val could be a problem.. after we removed the keys (or tried it) they
> were deleted and in the keys=keys output only 3 (was 4 before) are
> listed. So somehow the increasing n_val from 3 to 12 (factor 4...) and
> then reducing again to 3 could be the problem. But I have no clue why
> this should be the case.
> 
> Cheers,
> Simon
> 
> On Thu, 7 Mar 2013 11:30:40 +0100
> Simon Effenberg <[email protected]> wrote:
> 
> > Hi Mark,
> > 
> > we have 12 Riak nodes running. The exact command for getting keys is:
> > 
> > curl http://localhost:8098/buckets/config/keys?keys=true
> > 
> > Properties are:
> > 
> > curl -s http://localhost:8098/riak/config | python -mjson.tool
> > {
> >     "props": {
> >         "allow_mult": true, 
> >         "basic_quorum": false, 
> >         "big_vclock": 50, 
> >         "chash_keyfun": {
> >             "fun": "chash_std_keyfun", 
> >             "mod": "riak_core_util"
> >         }, 
> >         "dw": "quorum", 
> >         "last_write_wins": false, 
> >         "linkfun": {
> >             "fun": "mapreduce_linkfun", 
> >             "mod": "riak_kv_wm_link_walker"
> >         }, 
> >         "n_val": 3, 
> >         "name": "config", 
> >         "notfound_ok": true, 
> >         "old_vclock": 86400, 
> >         "postcommit": [], 
> >         "pr": 0, 
> >         "precommit": [], 
> >         "pw": 0, 
> >         "r": "quorum", 
> >         "rw": "quorum", 
> >         "small_vclock": 50, 
> >         "w": "quorum", 
> >         "young_vclock": 20
> >     }
> > }
> > 
> > you see that the n_val is now at 3 because of a bug in our tool which uses 
> > the Java client incorrect. Nevertheless we got multiple keys:
> > 
> > curl -s http://localhost:8098/buckets/config/keys?keys=true | python 
> > -mjson.tool | sort | uniq -c 
> >       4         
> > "com.xx.xx.xxx.yyy.yyy.yyy.BlockedAdFilterFactory:blocked-ads"
> >       ....
> > 
> > We are using a n_val of 12 to get something like a DC awareness. Our 
> > software creates 4 buckets and one (the config bucket) is really small and 
> > another isn't that big. But both are important in a case of a split brain 
> > (inter DC connection went down). The other buckets holding most of the data 
> > are either distinct or can easily be merged.
> > 
> > We wanted to reproduce this but our problem is, the keys can't be really 
> > removed. I mean they are removed and you can't 'GET' them anymore and also 
> > a 'DELETE' is complaining about this fact and you can create the key again, 
> > fetch it again, remove it again but in the 
> > http://localhost:8098/buckets/config/keys?keys=true they are not 
> > disappearing (even after a rolling restart of the cluster).
> > 
> > Cheers,
> > Simon
> > 
> > 
> > On Wed, 6 Mar 2013 11:59:55 -0600
> > Mark Phillips <[email protected]> wrote:
> > 
> > > Hey Simon,
> > > 
> > > A few questions for starters:
> > > 
> > > How many Riak nodes are in your cluster?
> > > Is your R still the default of 2?
> > > Out of curiosity, what's the use case for an n_val of 12? I think the
> > > highest I've ever seen is 5 or 6. :)
> > > 
> > > Mark
> > > 
> > > On Wed, Mar 6, 2013 at 10:28 AM, Simon Effenberg
> > > <[email protected]> wrote:
> > > > Hi,
> > > >
> > > > we changed the n_val of a bucket from 3 to 12. If we are now doing this:
> > > >
> > > > riak:8098/riak/config?keys=true
> > > > or
> > > > riak:8098/buckets/config/keys?keys=true
> > > >
> > > > we get some keys multiple times. Getting the content works
> > > > well but we can't rely on the output (or have to sort/uniq the output).
> > > >
> > > > Is this a normal behavior or is it a bug? (Riak 1.3.0 is used with
> > > > eleveldb as backend).
> > > >
> > > > Cheers,
> > > > Simon
> > > >
> > > > _______________________________________________
> > > > riak-users mailing list
> > > > [email protected]
> > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> > 
> > 
> > -- 
> > Simon Effenberg | Site Ops Engineer | mobile.international GmbH
> > Fon:     + 49-(0)30-8109 - 7173
> > Fax:     + 49-(0)30-8109 - 7131
> > 
> > Mail:     [email protected]
> > Web:    www.mobile.de
> > 
> > Marktplatz 1 | 14532 Europarc Dreilinden | Germany
> > 
> > 
> > Geschäftsführer: Malte Krüger
> > HRB Nr.: 18517 P, Amtsgericht Potsdam
> > Sitz der Gesellschaft: Kleinmachnow 
> > 
> > _______________________________________________
> > riak-users mailing list
> > [email protected]
> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 
> 
> -- 
> Simon Effenberg | Site Ops Engineer | mobile.international GmbH
> Fon:     + 49-(0)30-8109 - 7173
> Fax:     + 49-(0)30-8109 - 7131
> 
> Mail:     [email protected]
> Web:    www.mobile.de
> 
> Marktplatz 1 | 14532 Europarc Dreilinden | Germany
> 
> 
> Geschäftsführer: Malte Krüger
> HRB Nr.: 18517 P, Amtsgericht Potsdam
> Sitz der Gesellschaft: Kleinmachnow 
> 
> _______________________________________________
> riak-users mailing list
> [email protected]
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com


-- 
Simon Effenberg | Site Ops Engineer | mobile.international GmbH
Fon:     + 49-(0)30-8109 - 7173
Fax:     + 49-(0)30-8109 - 7131

Mail:     [email protected]
Web:    www.mobile.de

Marktplatz 1 | 14532 Europarc Dreilinden | Germany


Geschäftsführer: Malte Krüger
HRB Nr.: 18517 P, Amtsgericht Potsdam
Sitz der Gesellschaft: Kleinmachnow 

_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to