Minimal number of nodes for production

Tom Zeng tom at intridea.com
Wed Apr 10 18:23:18 EDT 2013


That's good recommendation, thanks:-).  I will have a 10-15 node
environment up for R&D soon, will do some benchmarking in that environment.

On Wed, Apr 10, 2013 at 6:17 PM, Eric Redmond <eredmond at basho.com> wrote:

> I certainly won't get drawn into a public debate about which database is
> faster per node, but I would recommend you never take such claims at face
> value.
>
> Eric
>
>
> On Apr 10, 2013, at 3:02 PM, Tom Zeng <tom at intridea.com> wrote:
>
> Thanks Eric for the info, that's very helpful.  7 was mentioned at the
> last Riak DC meetup. not as the minimal but for better performance, when I
> was chatting with a couple of Basho devs about performance benchmarking,
> and about Riak is quite a bit slower on single node against Mongo.
>
>
> On Wed, Apr 10, 2013 at 5:56 PM, Eric Redmond <eredmond at basho.com> wrote:
>
>>
>>
>> On Apr 10, 2013, at 2:26 PM, Tom Zeng <tom at intridea.com> wrote:
>>
>> Hi list,
>>
>> We have a production installation with only 3 nodes and running on 1.2.1.
>>  I'd appreciate to get some  facts to convince IT to increase the number of
>> nodes to 7 and upgrade to 1.3.  I heard people from Basho mentioned ideally
>> 7 nodes for production a couple of time, can someone explain why 7, is 4,
>> or 5 nodes good enough?
>>
>>
>> I'm not sure where you heard the number 7 as a minimum, unless if was for
>> a specific use-case. In general the minimum recommended number is 5 nodes.
>>
>> Running with only 3 nodes isn't a great idea. Since a core purpose of
>> Riak is to remain available in the face of outages, 3 will not support any
>> outage. Less than 3 is lower than the default replication value (N=3). This
>> is so important, in fact, that we recommend 5 solely to act as a buffer in
>> the case where 1 of the 5 is down, the remaining 4 is dangerously close to
>> the inflexible 3 node number. Even if you do not upgrade to 1.3, you really
>> need to have at least 5 nodes.
>>
>> There are many benefits to upgrading to 1.3, but one of the most
>> compelling from an operations point of view is active anti-entropy (AAE).
>> Rather than waiting on read-repair to fix inconsistent values (which is
>> passive), AAE routinely attempts to keep all node values in sync. This can
>> be a godsend if a node goes down, since you don't need to fore read-repair
>> when you bring the node back up by reading every key... you just let your
>> cluster actively self-heal.
>>
>>
>> Also on the 3 three nodes, the file size for the bitcask directory very
>> quite a bit: 21GB, 14GB, and 20GB. Could the node with only 14GB missing
>> something or it's expected to have such big difference?
>>
>>
>> There are several reasons sizes could be different. Values are not
>> yet/ever replicated (based on your N and W values). Files may have not been
>> compacted. Some keys have been deleted but not yet reaped...
>>
>> Thanks,
>> Tom
>>
>> --
>> Tom Zeng
>> Director of Engineering
>> Intridea, Inc. | www.intridea.com
>> tom at intridea.com
>> (o) 888.968.4332 x519
>> (c) 240-643-8728
>>  _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20130410/3493f656/attachment.html>


More information about the riak-users mailing list