Agreed. I haven't dug into the administration/cluster functionality of Riak yet (any version), but these changes all look excellent, esp based on what I've read about clustering in the past. Very excited for the 1.0 release :-) *
<http://www.loomlearning.com/> Jonathan Langevin Systems Administrator Loom Inc. Wilmington, NC: (910) 241-0433 - jlange...@loomlearning.com - www.loomlearning.com - Skype: intel352 * On Wed, Sep 7, 2011 at 9:30 PM, Alexander Sicular <sicul...@gmail.com>wrote: > Seconded, force-remove. > > @siculars > http://siculars.posterous.com > > Sent from my rotary phone. > On Sep 7, 2011 9:14 PM, "Nicholas Campbell" <nicholas.j.campb...@gmail.com> > wrote: > > +1 to force-remove. Clear is better than less typing (to a point). > > > > This sounds great! > > > > - Nick Campbell > > > > http://digitaltumbleweed.com > > > > > > On Wed, Sep 7, 2011 at 8:12 PM, Joseph Blomstedt <j...@basho.com> wrote: > > > >> Given that 1.0 prerelease packages are now available, I wanted to > >> mention some changes to Riak's clustering capabilities in 1.0. In > >> particular, there are some subtle semantic differences in the > >> riak-admin commands. More complete docs will be updated in the near > >> future, but I hope a quick email suffices for now. > >> > >> [nodeB/riak-admin join nodeA] is now strictly one-way. It joins nodeB > >> to the cluster that nodeA is a member of. This is semantically > >> different than pre-1.0 Riak in which join essentially joined clusters > >> together rather than joined a node to a cluster. As part of this > >> change, the joining node (nodeB in this case) must be a singleton > >> (1-node) cluster. > >> > >> In pre-1.0, leave and remove were essentially the same operation, with > >> leave just being an alias for 'remove this-node'. This has changed. > >> Leave and remove are now very different operations. > >> > >> [nodeB/riak-admin leave] is the only safe way to have a node leave the > >> cluster, and it must be executed by the node that you want to remove. > >> In this case, nodeB will start leaving the cluster, and will not leave > >> the cluster until after it has handed off all its data. Even if nodeB > >> is restarted (crashed/shutdown/whatever), it will remain in the leave > >> state and continue handing off partitions until done. After handoff, > >> it will leave the cluster, and eventually shutdown. > >> > >> [nodeA/riak-admin remove nodeB] immediately removes nodeB from the > >> cluster, without handing off its data. All replicas held by nodeB are > >> therefore lost, and will need to be re-generated through read-repair. > >> Use this command carefully. It's intended for nodes that are > >> permanently unrecoverable and therefore for which handoff doesn't make > >> sense. By the final 1.0 release, this command may be renamed > >> "force-remove" just to make the distinction clear. > >> > >> There are now two new commands that provide additional insight into > >> the cluster. [riak-admin member_status] and [riak-admin ring_status]. > >> > >> Underneath, the clustering protocol has been mostly re-written. The > >> new approach has the following advantages: > >> 1. It is no longer necessary to wait on [riak-admin ringready] in > >> between adding/removing nodes from the cluster, and adding/removing is > >> also much more sound/graceful. Starting up 16 nodes and issuing > >> [nodeX: riak-admin join node1] for X=1:16 should just work. > >> > >> 2. Data is first transferred to new partition owners before handing > >> over partition ownership. This change fixes numerous bugs, such as > >> 404s/not_founds during ownership changes. The Ring/Pending columns in > >> [riak-admin member_status] visualize this at a high-level, and the > >> full transfer status in [riak-admin ring_status] provide additional > >> insight. > >> > >> 3. All partition ownership decisions are now made by a single node in > >> the cluster (the claimant). Any node can be the claimant, and the duty > >> is automatically taken over if the previous claimant is removed from > >> the cluster. [riak-admin member_status] will list the current > >> claimant. > >> > >> 4. Handoff related to ownership changes can now occur under load; > >> hinted handoff still only occurs when a vnode is inactive. This change > >> allows a cluster to scale up/down under load, although this needs to > >> be further benchmarked and tuned before 1.0. > >> > >> To support all of the above, a new limitation has been introduced. > >> Cluster changes (member addition/removal, ring rebalance, etc) can > >> only occur when all nodes are up and reachable. [riak-admin > >> ring_status] will complain when this is not the case. If a node is > >> down, you must issue [riak-admin down <node>] to mark the node as > >> down, and the remaining nodes will then proceed to converge as usual. > >> Once the down node comes back online, it will automatically > >> re-integrate into the cluster. However, there is nothing preventing > >> client requests being served by a down node before it re-integrates. > >> Before issuing [down <node>], make sure to update your load balancers > >> / connection pools to not include this node. Future releases of Riak > >> may make offlining a node an automatic operation, but it's a > >> user-initiated action in 1.0. > >> > >> -Joe > >> > >> _______________________________________________ > >> 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 > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
