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> *On Behalf Of
*Fred Dushin
*Sent:* 01 February 2019 22:47
*To:* 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.
1. Choose target node.
2. Make target node leave cluster as in a full “riak-admin
cluster leave”, commit and wait for transfers to finish.
3. Set up target node with leveled and TicTac AAE.
4. Have node rejoin cluster and wait for transfers to finish.
5. 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 seehttps://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
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;
- 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.
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/).
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
