Wouldn't it be better to do a `riak-admin replace`? Leave could be problematic if there are other nodes in the cluster that are under-provisioned (disk space, for example). Plus a leave and add would move the data around the cluster twice, for each node in the cluster, whereas a replace would just move the data to the new node once, no?
-Fred > On Feb 1, 2019, at 8:32 AM, Nicholas Adams <nicholas.ad...@tiot.jp> wrote: > > Hi Guido, > Although Martin would be the most qualified to comment on this, I believe you > should be able to do a slow migration. > > Choose target node. > Make target node leave cluster as in a full “riak-admin cluster leave”, > commit and wait for transfers to finish. > Set up target node with leveled and TicTac AAE. > Have node rejoin cluster and wait for transfers to finish. > Repeat with every single node in the cluster until all have been done. > > Unless you are using specific features restricted to your current backend > then Riak will usually put up with multiple backends in the same cluster. > > Failing that, I’d go with Bryan’s suggestion to use MDC to replicate from > your existing cluster to a separate cluster that is using the leveled backend > and TicTac AAE. > > Either way, be sure to try in a dev environment first and only proceed when > you are happy with the process. > > Best regards, > > Nicholas > > From: riak-users <riak-users-boun...@lists.basho.com> On Behalf Of Bryan Hunt > Sent: 01 February 2019 19:22 > To: Guido Medina <gmed...@temetra.com> > Cc: riak-users@lists.basho.com > Subject: Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available > > Replication would be the optimum solution - in theory anything can be > implemented - but it would be enormously painful in comparison to simply > standing up a new cluster. > > > On 1 Feb 2019, at 10:14, Guido Medina <gmed...@temetra.com > <mailto:gmed...@temetra.com>> wrote: > > Hi all, > > Nice work on the upcoming 2.9.0 release, I have a quick question: > Will it be possible to switch from the eleveldb to the new leveled backend > and Tictac AAE for an existing cluster? > > In case it is not possible we are thinking to use the new replication and > move to a brand new cluster. > > Kind regards, > Guido. > > On 30/01/2019 15:23, Nicholas Adams wrote: > Dear All, > Following on from Martin’s email, the initial builds of the KV 2.9.0rc1 > packages are complete. Currently we are limited to Redhat/CentOS 6 and 7 as > well as Ubuntu Bionic. We shall be adding more packages over the next few > days. Please see https://files.tiot.jp/riak/kv/2.9/2.9.0rc1/ > <https://files.tiot.jp/riak/kv/2.9/2.9.0rc1/> to download. > > Disclaimer: This is a release candidate. Please do not use in production as > we expect bugs and abnormal functionality may occur in certain conditions. > However, please test this lots and place any issues on github so that they > can be fixed before the final release. > > Best regards, > > Nicholas > > From: riak-users <riak-users-boun...@lists.basho.com> > <mailto:riak-users-boun...@lists.basho.com> On Behalf Of Martin Sumner > Sent: 30 January 2019 21:07 > To: riak-users@lists.basho.com <mailto:riak-users@lists.basho.com> > Subject: [ANN] Riak 2.9.0 - Release Candidate 1 Available > > All, > > There is now a publicly available release candidate for Riak 2.9.0 for users > to test in their own environment. The release candidate is available to > build from source here - https://github.com/basho/riak/tree/riak-2.9.0rc1 > <https://github.com/basho/riak/tree/riak-2.9.0rc1> > > There is only one significant change to Riak 2.2.6 for users maintaining > existing configuration settings. The release adds the `vnode_soft_limits` > feature that aims to reduce high percentile PUT latency, by checking the > outstanding work queue for a vnode before selecting it as a coordinator of a > PUT. > > With additional configuration, there are two major features added in riak > 2.9.0: > > - Support for the leveled backend (as an alternative to bitcask or eleveldb), > to provide for improved throughput in some use cases and lower tail latency > in some use cases > -https://github.com/martinsumner/riak_testing_notes/blob/master/Release%202.9%20-%20Choosing%20a%20Backend.md > > <https://github.com/martinsumner/riak_testing_notes/blob/master/Release%202.9%20-%20Choosing%20a%20Backend.md>; > - Support for a new anti-entropy mechanism (Tictac AAE) as an alternative for > the existing anti-entropy mechanism (to provide both intra-cluster and > inter-cluster data repair, with greater flexibility and reliability). > > The release also adds support for: > - The riak_core node_worker_pool - which provides a mechanism for queueing > background jobs and queries to control the resource consumed on the node by > different queries. No pre-existing features will use the node-worker_pool. > - AAE folds which allow for both cluster-wide AAE queries (e.g. produce a > merkle tree representing all or a partial range of the cluster data), and > administrative queries (e.g. discovering object sizes and sibling counts > within the database depending on bucket name, key range and last modified > date). AAE folds depend on the Tictac AAE feature being activated. > - An interface to request re-replication of an object (where variances > between clusters have been discovered). > > Further details of the release, and the release plan in general can be found > here - > https://github.com/basho/riak/blob/develop-2.9/doc/Release%202.9%20Series%20-%20Overview.md > > <https://github.com/basho/riak/blob/develop-2.9/doc/Release%202.9%20Series%20-%20Overview.md>. > > It is hoped that there will be a short period of about 1 month before the > release candidate will be converted into a formal release. The period will > allow for more testing by Riak users, and also there will be further enhanced > testing of the new modules with the help of Quviq (http://www.quviq.com/ > <http://www.quviq.com/>). > > There will follow additional releases under the 2.9 banner, targeted at > enhancing both new and existing inter-cluster replication features. In > parallel to this, work will continue on Release 3.0 which is intended to > modernise the OTP/rebar platform used by Riak. > > Thanks to all those who contributed to the release. Apologies to those who > have been kept waiting over the past few months as finalising the changes and > completing the testing has dragged on. > > Regards > > Martin > > > > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com <mailto:riak-users@lists.basho.com> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > <http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com> > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com <mailto:riak-users@lists.basho.com> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > <http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com> > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
