I like this idea. I'd add that the "write only node" (the added node) could simply do a "streaming vnode list keys" operation (not that it exists--does it?) and basically do a read repair on all of those keys to "catch up" to the vnode's previous status. Maybe while it is catching up it could simply buffer the incoming write operations and replay them later. Once that buffer is empty it can effectively take over the vnode and start answering queries.
-jd 2011/5/5 Mike Oxford <[email protected]> > As someone not familiar with Riak's internals... > > You have xN replication. > Make the transition-nodes be part of an x(N+1) and write-only (eg, they > don't count in the read quorum.) > > If you're set up for x3 replication, then the transition bucket ends up as > part of an x4 replication. > As more queries come in, you will get up to 4 responses, but the write-only > response gets tossed. > A split would give you up to a 2x2 where it's really 2x1+1 and you can > rebuild normally. > Once your x4 replication is consistant you remove one node from the > replication set, taking you back to 3. > > This, while not trivial, seems to leverage many of the pieces you already > have in place and avoids the > problem of "slow replication fubars requests for indeterminate amounts of > time." > > Just a suggestion from the peanut gallery... :) > > -mox > > >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
