Hi Daniel, Thank you for clearing that up (and filing the rack-aware case). Y'all might want to add your clarification to https://wiki.basho.com/display/RIAK/Replication (So what does N=3 really mean?). That page makes it sound like there's no guarantees of separation at all, whereas I understand your explanation to mean there will be N-1 replicas on different physical nodes, if there are N-1 physical nodes available. Thank you again!
-J On Sat, Jun 12, 2010 at 4:00 PM, Dan Reverri <d...@basho.com> wrote: > Hi Jason, > Regarding rack-aware distribution, at this time Riak is not rack-aware. I've > filed a request in Bugzilla for this feature: > http://issues.basho.com/show_bug.cgi?id=245 > Regarding general replica distribution, Riak guarantees that replicas will > be placed on at least N-1 distinct nodes when physically possible*. This > means for N=3, replicas will be placed on at least 2 distinct nodes. In most > cases replicas will be placed on N distinct nodes but there are some > degenerate cases where replicas are only placed on 2 nodes. More information > can be found here: > http://issues.basho.com/show_bug.cgi?id=228 > *When physically possible refers to having at least N physical nodes > available. Meaning you can't place 3 replicas on distinct nodes if you only > have 2 nodes. > Thanks, > Dan > Daniel Reverri > Developer Advocate > Basho Technologies, Inc. > d...@basho.com > > > On Wed, Jun 9, 2010 at 1:47 PM, Jason J. W. Williams > <jasonjwwilli...@gmail.com> wrote: >> >> Hi David, >> >> Thank you for responding. On a separate note, will there be any way to >> make Riak rack-aware for data distribution? >> >> It's concerning for removing nodes that you can't guarantee there >> aren't at least 2 out of 3/4 copies on different nodes. >> >> -J >> >> On Wed, Jun 9, 2010 at 2:21 PM, David Smith <diz...@basho.com> wrote: >> > Jason, >> > Our testing has shown bitcask to have as good recovery as DETS (the >> > previous >> > default backend), and MUCH better overall performance. However, I'm >> > going to >> > stop short of saying definitively that the recovery of bitcask is as >> > good >> > as/better than innostore, simply because we don't have enough data to >> > support it...yet. :) >> > I will say, however, that the append-only nature of bitcask minimizes >> > the >> > opportunity to lose and/or corrupt data, not to mention obviating the >> > need >> > for log files ala InnoDB. >> > D. >> > >> > On Wed, Jun 9, 2010 at 1:59 PM, Jason J. W. Williams >> > <jasonjwwilli...@gmail.com> wrote: >> >> >> >> Does the bitcask back end handle crash recovery as well as the >> >> InnoStore backend? >> >> >> >> -J >> >> >> >> On Wed, Jun 9, 2010 at 1:55 PM, Jon Meredith <jmered...@basho.com> >> >> wrote: >> >> > Hello, Riak users. We are excited to announce the release of Riak >> >> > version >> >> > 0.11. >> >> > >> >> > Pre-built installations and source tarballs are available at: >> >> > http://downloads.basho.com/ >> >> > >> >> > Release notes are at (also copied below): >> >> > http://downloads.basho.com/riak/riak-0.11/riak-0.11.0.txt >> >> > >> >> > IMPORTANT: If you are upgrading an existing Riak cluster, please read >> >> > the >> >> > transition document at >> >> > http://bitbucket.org/basho/riak/src/4235ceeb8d6/TRANSITION >> >> > >> >> > Cheers, >> >> > The Basho Riak Team >> >> > >> >> > ------------------------- >> >> > Riak 0.11.0 Release Notes >> >> > ------------------------- >> >> > >> >> > Bitcask has arrived as the new default backend for Riak. Bitcask is >> >> > Basho's >> >> > new key/value store that should provide good balanced performance out >> >> > of the box on most systems. Read more about it from the initial >> >> > announcement here http://blog.basho.com/2010/04/27/hello,-bitcask/ >> >> > >> >> > Users that wish to upgrade from another backend will need to backup >> >> > their >> >> > cluster (using riak-admin) before changing the backend in app.config, >> >> > restart >> >> > riak and restore from the backup into bitcask. >> >> > >> >> > The protocol buffers client (PBC) interface has been enhanced to >> >> > add map/reduce support and access to simple bucket properties. The >> >> > erlang and python clients have been updated accordingly. >> >> > >> >> > Put operations using the local erlang client that request a >> >> > returnbody >> >> > have received a performance enhancement. Internally the put >> >> > operation >> >> > now returns the body directly, so an additional get is no longer >> >> > required. The PBC and HTTP interfaces have been updated to use >> >> > this new mechanism. >> >> > >> >> > Enhancements >> >> > -------- >> >> > 58 - provide default content-type of application/octet-stream if >> >> > none >> >> > present in the object. >> >> > 74 - create ring directory if non-existant >> >> > 142 - riak-admin leave restored >> >> > >> >> > Bugs Fixed >> >> > ---------- >> >> > 35 - {error, blah} messages are now passed on to javascript >> >> > map/reduce >> >> > jobs >> >> > 104 - missing bucket/key into map/reduce job crashed it. Fixed. >> >> > 193 - list keys sometimes uses downed nodes. Fixed. >> >> > 208 - deleting a key with a post-commit hook set crashed riak. Fixed. >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 > > _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com