Riak KV 2.1.1 Release Notes

NOTE: Riak 2.1.1 has replaced Riak 2.1.0

Fixes

Riak 2.1.0 introduced a bug that has been fixed in Riak 2.1.1. The default configuration for handoff.ip caused vnodes marked for transfer during handoff to be removed without transferring data to their new destination nodes. A mandatory change to configuration (riak.conf) mitigates this issue for 2.1.0 users. While not all users were impacted by this issue, we recommend that all 2.1.0 users upgrade to 2.1.1.

Detailed information on the issue is available in the Riak Documentation Product Advisories.

  • Make default handoff_ip value 0.0.0.0 in vars.config.

Riak 2.1.0 Release Notes

New Features

Performance Improvements

The introduction of write-once buckets allows users to experience up to a 2x performance improvement for write-heavy, write-once workloads. More details on implementing write-once buckets are available below.

Write-Once Bucket Type

Riak 2.1.0 introduces the concept of write-once buckets, buckets whose entries are intended to be written exactly once and never updated or overwritten. Since objects are intended to only be written once, Riak does not perform the usual “get, merge, update” cycle which reduces IOPs and improves throughput and latency.

It is still possible for multiple entries to be written to a single key – through mis-use of the API, network partitions, simultaneous writes, etc.. In these cases, Riak will always resolve siblings using an algorithm based on the SHA-1 hashes of the conflicting objects. While this algorithm is repeatable and deterministic at the database level, it will have the appearance to the user of “random write wins”.

The write_once property is a boolean value applied to a bucket type and may only be set at bucket creation time. Once a bucket type has been set and activated with the write_once property, the property may not be modified

Limitations:

  • Pre/Post-commit hooks are not supported.
  • Large object warnings and limits are not enforced.
  • All nodes must be upgraded before enabling write_once - usage in mixed clusters will crash vnodes.

Changes

  • Issue kv679 - Applies fix to most causes of data loss from repeated causal history. A monotonic counter is fsynced to disk when the vnode starts. Thus starting/re-starting a vnode has a cost associated that was not there before.

  • Update API to retrieve active preflist based on particular bucket/key. Updates the Riak API with an operation to GET, e.g. /types/Type/buckets/Bucket/keys/Key/preflist, an annotated (nodes being primary or fallback) preflist of which nodes host a particular bucket/key combination is returned.

  • Add a JSON writer for several riak-admin commands, including cluster status, cluster partition[s], cluster partition-count, any of the riak-admin handoff commands, and riak-admin set/show/describe.

  • Integrate performance patches into Erlang R16 VM used by Riak.

  • Add riak_core_ring_manager:is_stable_ring/0 to public API. Allows clients to ensure that the ring has not changed in X seconds (currently 90).

  • yokozuna/issues/468 - Add search_query_latency_mean and search_index_latency_mean metrics.

Fixes

Known Issues

  • yokozuna/issues/481 - Search loses entries when Search AAE trees expire. We are currently investigating this issue.
  • riak/issues/727 - Users upgrading from 1.4.x to 2.1.x that choose to use the traditional app.config for configuration should be aware that the default settings for allow_mult and dvv_enabled have changed from false to true between these versions. If your application depends on these being set to ‘false’, you must explicitly define this by adding {default_bucket_props, [{allow_mult, false}, {dvv_enabled, false}]}, to the riak_core section of your app.config file to maintain backwards compatibility.

Notes on upgrading

  • Write-Once Buckets
    • If you make use of write-once buckets, you must upgrade all of your Riak nodes in a cluster to 2.1.0. There is no support for write-once buckets in a cluster with mixed Riak versions.
    • Pre/Post-commit hooks are not supported.
    • Large object warnings and limits are not enforced