Skip to content

Commit

Permalink
Update release notes for 1.0.2 changes
Browse files Browse the repository at this point in the history
  • Loading branch information
@jaredmorrow
jaredmorrow committed Nov 5, 2011
1 parent ea6491b commit f9f49d8
Showing 1 changed file with 101 additions and 65 deletions.
166 changes: 101 additions & 65 deletions RELEASE-NOTES.org
View file
Original file line number Diff line number Diff line change
@@ -1,3 +1,104 @@
* Riak 1.0.2 Release Notes
** Bugs Fixed
-[[https://issues.basho.com/show_bug.cgi?id=1227][bz1227 - badstate crash in handoff]]
-[[https://issues.basho.com/show_bug.cgi?id=1261][bz1261 - pipe mapreduce jobs fail in mixed 1.0.0/1.0.1 clusters]]
-[[https://issues.basho.com/show_bug.cgi?id=1263][bz1263 - bitcask-backed vnodes handle requests while dropping]]
-[[https://issues.basho.com/show_bug.cgi?id=1265][bz1265 - eleveldb not opened with configuration options from environment]]
-[[https://issues.basho.com/show_bug.cgi?id=1271][bz1271 - Can't replicate between 1.0 and 0.14 clusters]]

** Other Additions
*** New stats
Two new stats categories have been added to riak stats.

-=node_get_fsm_siblings= reports the statstics on the number of siblings retrieved with get over the last minute.
-=node_get_fsm_objsize= reports an estimate of the object sizes retrieved with get over the last minute.

For both categories mean, median, max, 95th & 99th percentiles are given.
The new stats are available using riak-admin status or from the /stats endpoint.
** Known Issues
*** Pipe based MapReduce during rolling upgrades
[[https://issues.basho.com/show_bug.cgi?id=1261][BZ1261]]
A bug was found that caused pipe-based MapReduce to be
unusable during rolling upgrades from 1.0.0 to 1.0.1 (they work again
once the upgrade is complete). The problem has been fixed such that
MapReduce will stay available when upgrading from 1.0.1 to 1.0.2, and
also from 1.0.2 onward.

If you are still using Riak 1.0.0, pipe-based MapReduce will still be
unusable during the rolling upgrade to 1.0.2. We apologize for the
inconvenience. If your MapReduce queries work on the legacy
subsystem, you may want to switch back to it for the duration of your
upgrade to 1.0.2. To switch MapReduce subsystems, either edit the
'mapred_system' setting in your app.config and restart each node, or
connect to each nodes console and evaluate
'application:set_env(riak_kv, mapred_system, Choice).' where 'Choice'
is either 'legacy' or 'pipe'.

*** Large Ring Sizes

The new cluster protocol in 1.0 leads to a practical limit on the size
of the ring in a Riak cluster. While there is no hard coded limit, large
ring sizes lead to increasingly slower performance and potentially unstable
clusters. This limitation will be addressed in a future major release of
Riak. For the time being, it is recommended that users limit clusters to
no more than 256, 512, 1024 partitions depending on the performance of the
underlying hardware.

*** Ownership Handoff Stall

It has been observed that 1.0 clusters can end up in a state with ownership
handoff failing to complete. This state should not happen under normal
circumstances, but has been observed in cases where Riak nodes crashed due
to unrelated issues (eg. running out of disk space/memory) during cluster
membership changes. The behavior can be identified by looking at the output
of =riak-admin ring_status= and looking for transfers that are waiting on an
empty set. As an example:

#+BEGIN_SRC
============================== Ownership Handoff ==============================
Owner: riak@host1
Next Owner: riak@host2

Index: 123456789123456789123456789123456789123456789123
Waiting on: []
Complete: [riak_kv_vnode,riak_pipe_vnode]
#+END_SRC

To fix this issue, copy/paste the following code sequence into an Erlang
shell for each =Owner= node in =riak-admin ring_status= for which
this case has been identified. The Erlang shell can be accessed with =riak attach=

#+BEGIN_SRC
fun() ->
Node = node(),
{_Claimant, _RingReady, _Down, _MarkedDown, Changes} =
riak_core_status:ring_status(),
Stuck =
[{Idx, Complete} || {{Owner, NextOwner}, Transfers} <- Changes,
{Idx, Waiting, Complete, Status} <- Transfers,
Owner =:= Node,
Waiting =:= [],
Status =:= awaiting],

RT = fun(Ring, _) ->
NewRing = lists:foldl(fun({Idx, Mods}, Ring1) ->
lists:foldl(fun(Mod, Ring2) ->
riak_core_ring:handoff_complete(Ring2, Idx, Mod)
end, Ring1, Mods)
end, Ring, Stuck),
{new_ring, NewRing}
end,

case Stuck of
[] ->
ok;
_ ->
riak_core_ring_manager:ring_trans(RT, []),
ok
end
end().
#+END_SRC

* Riak 1.0.1 Release Notes
** Bugs Fixed
-[[https://issues.basho.com/show_bug.cgi?id=15][bz0015 - Merge js-mapreduce.org and basic-mapreduce.txt]]
Expand Down Expand Up @@ -374,71 +475,7 @@ been observed when running multiple nodes on a single machine, and has
not been observed when running Riak on multiple servers or EC2
instances.

*** Large Ring Sizes

The new cluster protocol in 1.0 leads to a practical limit on the size
of the ring in a Riak cluster. While there is no hard coded limit, large
ring sizes lead to increasingly slower performance and potentially unstable
clusters. This limitation will be addressed in a future major release of
Riak. For the time being, it is recommended that users limit clusters to
no more than 256, 512, 1024 partitions depending on the performance of the
underlying hardware.

*** Ownership Handoff Stall

It has been observed that 1.0 clusters can end up in a state with ownership
handoff failing to complete. This state should not happen under normal
circumstances, but has been observed in cases where Riak nodes crashed due
to unrelated issues (eg. running out of disk space/memory) during cluster
membership changes. The behavior can be identified by looking at the output
of =riak-admin ring_status= and looking for transfers that are waiting on an
empty set. As an example:

#+BEGIN_SRC
============================== Ownership Handoff ==============================
Owner: riak@host1
Next Owner: riak@host2

Index: 123456789123456789123456789123456789123456789123
Waiting on: []
Complete: [riak_kv_vnode,riak_pipe_vnode]
#+END_SRC

To fix this issue, copy/paste the following code sequence into an Erlang
shell for each =Owner= node in =riak-admin ring_status= for which
this case has been identified. The Erlang shell can be accessed with =riak attach=

#+BEGIN_SRC
fun() ->
Node = node(),
{_Claimant, _RingReady, _Down, _MarkedDown, Changes} =
riak_core_status:ring_status(),
Stuck =
[{Idx, Complete} || {{Owner, NextOwner}, Transfers} <- Changes,
{Idx, Waiting, Complete, Status} <- Transfers,
Owner =:= Node,
Waiting =:= [],
Status =:= awaiting],

RT = fun(Ring, _) ->
NewRing = lists:foldl(fun({Idx, Mods}, Ring1) ->
lists:foldl(fun(Mod, Ring2) ->
riak_core_ring:handoff_complete(Ring2, Idx, Mod)
end, Ring1, Mods)
end, Ring, Stuck),
{new_ring, NewRing}
end,

case Stuck of
[] ->
ok;
_ ->
riak_core_ring_manager:ring_trans(RT, []),
ok
end
end().
#+END_SRC

** Bugs Fixed
-[[https://issues.basho.com/show_bug.cgi?id=0105][bz0105 - Python client new_binary doesn't set the content_type well]]
-[[https://issues.basho.com/show_bug.cgi?id=0123][bz0123 - default_bucket_props in app.config is not merged with the hardcoded defaults]]
Expand Down Expand Up @@ -519,6 +556,5 @@ end().
-[[https://issues.basho.com/show_bug.cgi?id=1220][bz1220 - riak-admin ringready only shows 1.0 nodes in a mixed cluster]]
-[[https://issues.basho.com/show_bug.cgi?id=1224][bz1224 - platform_data_dir (/data) is not being created before accessed for some packages]]
-[[https://issues.basho.com/show_bug.cgi?id=1226][bz1226 - Riak creates identical vtags for the same bucket/key with different values]]
-[[https://issues.basho.com/show_bug.cgi?id=1227][bz1227 - badstate crash in handoff]]
-[[https://issues.basho.com/show_bug.cgi?id=1229][bz1229 - "Downed" (riak-admin down) nodes don't rejoin cluster]]

0 comments on commit f9f49d8

Please sign in to comment.