Yeah - it used to be the case that it would be typical to rolling upgrade replace, leave, individual cluster nodes - but that was the era when :
a). It cost $5000 per node for a riak_repl (enterprise) license b) Most folk ran on physical hardware Now with most deployments (Bet366/NHS being notable exceptions) running on cloud, and no license fee to pay - it’s a no brainer to go the route of create new cluster, replicate, verify, switch over, archive old data. B > On 1 Feb 2019, at 14:08, Guido Medina <gmed...@temetra.com> wrote: > > We could probably go the "replace" way, but maybe we take this as a good > opportunity to increase our ring size, it is still something we are > considering. > > Resizing the cluster while operating daily is no joke, too much data and Riak > becomes extremely slow when we have to add a new node, so it would either go > the "replace" way or replicate and switch to the new cluster. > > Thanks for all the answers ;-) > Guido. > > On 01/02/2019 13:50, Nicholas Adams wrote: >> If he has an extra node he can add then a replace would be much better. I >> provided this example under the assumption that he had no additional >> resources to play with. >> >> Nicholas >> >> From: riak-users <riak-users-boun...@lists.basho.com> >> <mailto:riak-users-boun...@lists.basho.com> On Behalf Of Fred Dushin >> Sent: 01 February 2019 22:47 >> To: riak-users@lists.basho.com <mailto:riak-users@lists.basho.com> >> Subject: Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available >> >> 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 >> <mailto: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 >> <mailto:riak-users-boun...@lists.basho.com>> On Behalf Of Bryan Hunt >> Sent: 01 February 2019 19:22 >> To: Guido Medina <gmed...@temetra.com <mailto:gmed...@temetra.com>> >> Cc: riak-users@lists.basho.com <mailto: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 <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 <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
