[ANN] Riak 2.9.0 - Release Candidate 1 Available

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] Riak 2.9.0 - Release Candidate 1 Available

Martin Sumner
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Nicholas Adams

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/ 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 <[hidden email]> On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Guido Medina-3
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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com


_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Bryan Hunt-3
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 <[hidden email]> 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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

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


_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Nicholas Adams

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 <[hidden email]> On Behalf Of Bryan Hunt
Sent: 01 February 2019 19:22
To: Guido Medina <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com


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

 


_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Fred Dushin-2
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Bryan Hunt
Sent: 01 February 2019 19:22
To: Guido Medina <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

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


_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Nicholas Adams

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 <[hidden email]> On Behalf Of Fred Dushin
Sent: 01 February 2019 22:47
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Bryan Hunt
Sent: 01 February 2019 19:22
To: Guido Medina <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com


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

 

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

 


_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Fred Dushin-2
Lol.  Good point.

I always assume people have spares lying around..  My bad.

-Fred

On Feb 1, 2019, at 8:50 AM, Nicholas Adams <[hidden email]> 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 <[hidden email]> On Behalf Of Fred Dushin
Sent: 01 February 2019 22:47
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Bryan Hunt
Sent: 01 February 2019 19:22
To: Guido Medina <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

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


_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Guido Medina-3
In reply to this post by Nicholas Adams
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 [hidden email] On Behalf Of Fred Dushin
Sent: 01 February 2019 22:47
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Bryan Hunt
Sent: 01 February 2019 19:22
To: Guido Medina <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com


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

 

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

 


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


_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Riak 2.9.0 - Release Candidate 1 Available

Bryan Hunt-3
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 <[hidden email]> 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 [hidden email] On Behalf Of Fred Dushin
Sent: 01 February 2019 22:47
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Bryan Hunt
Sent: 01 February 2019 19:22
To: Guido Medina <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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/ 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 [hidden email] On Behalf Of Martin Sumner
Sent: 30 January 2019 21:07
To: [hidden email]
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
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

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

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

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


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