Do nodes always need to restart after backend selection?

Reid Draper reiddraper at gmail.com
Tue Apr 9 12:20:53 EDT 2013


I'd like to point out that changing backends and n-val on the fly is usually Not A Good Idea. Neither of these are things we test, nor advise. In both cases, they can leave data that is never deleted or cleaned up. Unless you have a really good reason for doing this, I'd strongly advise against it.

Reid

On Apr 4, 2013, at 10:42 PM, Toby Corkindale <toby.corkindale at strategicdata.com.au> wrote:

> Answering my own question again, but hopefully that saves you time.
> 
> So, it appears that if a backend is changed via the JSON REST API, then all keys from the previous backend are now inaccessible. I think this also indicates that now the new backend is in use immediately, without any restarts required.
> 
> May I suggest that the wording on the API Reference page is improved? Both I and a colleague misunderstood it to mean that *any* change of backend required a restart.
> 
> Cheers,
> Toby
> 
> On 05/04/13 11:27, Toby Corkindale wrote:
>> Hi Jared,
>> 
>> I'm afraid I am still a little confused after reading your reply, so I'd
>> like to check something.
>> 
>> If I understand correctly, the reboot of nodes is only required if the
>> default settings in app.config are changed, and one can change anything
>> else on-the-fly?
>> 
>> So therefore, in the following scenario, I could issue these commands
>> and never need to reboot any nodes?
>> 
>> Riak backend = Multi, with Bitcask (default) and Leveldb.
>> 
>> PUT /buckets/myBucket/myKey
>> # Key is stored in Bitcask
>> 
>> PUT /buckets/myNewBucket/props
>> { backend: Leveldb }
>> 
>> PUT /buckets/myBucket/myOtherKey
>> # Key is stored in Leveldb backend
>> 
>> 
>> If I change the backend, do I lose any keys that were previously
>> available in the original backend or are they migrated? (I'd expect to
>> lose them)
>> 
>> 
>> Thanks for your patience,
>> Toby
>> 
>> 
>> 
>> On 05/04/13 00:51, Jared Morrow wrote:
>>> Toby,
>>> 
>>> That particular page is talking about changing the default settings of
>>> the backend of a bucket.  In that specific case, if you want to change
>>> the default behavior in your app.config file a restart is necessary.
>>>  One particularly important detail there is you don't need to restart
>>> *all* nodes at the same time.  Restarting one node at a time is
>>> sufficient and recommended so you don't have any cluster downtime.
>>> 
>>> For setting common bucket properties, you do not need to restart the
>>> node.  If you want to change the n_val of a bucket for instance, you can
>>> just change it from your client on all nodes.  That page explains at the
>>> bottom how to set them on the erlang console or curl, but most people
>>> use their chosen client to set bucket properties before writing values.
>>>   Here is an example using the Java Client
>>> http://docs.basho.com/java/latest/cookbooks/buckets/.  In general it
>>> doesn't matter if your client supports HTTP or protocol buffers, both
>>> API's  support bucket
>>> property changes.
>>> 
>>> Hope that helps,
>>> Jared
>>> 
>>> On Wed, Apr 3, 2013 at 10:14 PM, Toby Corkindale
>>> <toby.corkindale at strategicdata.com.au
>>> <mailto:toby.corkindale at strategicdata.com.au>> wrote:
>>> 
>>>    Hi,
>>>    According to the docs at the following URL, it is necessary to
>>>    reboot all Riak nodes after setting the bucket property for backend.
>>>    This seems really drastic, and we'd like to avoid having to do this!
>>>    See:
>>> 
>>> http://docs.basho.com/riak/1.__3.0/tutorials/choosing-a-__backend/Multi/
>>> 
>>> <http://docs.basho.com/riak/1.3.0/tutorials/choosing-a-backend/Multi/>
>>> 
>>>    I wondered if the restart of the whole cluster can be avoided?
>>>    Perhaps we could set the bucket properties prior to setting any keys
>>>    within it?
> 
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com





More information about the riak-users mailing list