kload
>
>
>
> Option (a) will impact more the cluster stability than (b).
>
>
>
> Dominique
>
>
>
> [@@ THALES GROUP INTERNAL @@]
>
>
>
> *De :* Kant Kodali [mailto:k...@peernova.com]
> *Envoyé :* samedi 17 décembre 2016 22:21
> *À :* user@cassandra.apache.o
% workload
Option (a) will impact more the cluster stability than (b).
Dominique
[@@ THALES GROUP INTERNAL @@]
De : Kant Kodali [mailto:k...@peernova.com]
Envoyé : samedi 17 décembre 2016 22:21
À : user@cassandra.apache.org
Objet : quick questions
I keep hearing that the minimum number of
Thanks! got it!
On Sat, Dec 17, 2016 at 5:02 PM, Max C wrote:
> As Matija mentioned, quorum is RF / 2 + 1:
>
> RF=1, Quorum = 1
> RF=2, Quorum = 2
> RF=3, Quorum = 2
> RF=4, Quorum = 3
> RF=5, Quorum = 3
> RF=6, Quorum = 4
> RF=7, Quorum = 4
>
> So no, you don’t have to have an odd RF to achieve
As Matija mentioned, quorum is RF / 2 + 1:
RF=1, Quorum = 1
RF=2, Quorum = 2
RF=3, Quorum = 2
RF=4, Quorum = 3
RF=5, Quorum = 3
RF=6, Quorum = 4
RF=7, Quorum = 4
So no, you don’t have to have an odd RF to achieve a quorum, as you see above.
Most people use RF=3 with a minimum of 3 nodes, though
@Matjia I think you either did not understand my question or I failed to
explain it more clearly.
On Sat, Dec 17, 2016 at 4:46 PM, Matija Gobec wrote:
> QUORUM is by documentation:
>
> quorum = (sum_of_replication_factors / 2) + 1
>
> Its not fixed value (as 4).
>
> On Sat, Dec 17, 2016 at 10:21
QUORUM is by documentation:
quorum = (sum_of_replication_factors / 2) + 1
Its not fixed value (as 4).
On Sat, Dec 17, 2016 at 10:21 PM, Kant Kodali wrote:
> I keep hearing that the minimum number of Cassandra nodes required to
> achieve Quorum consensus is 4 I wonder why not 3? In fact, many c
I keep hearing that the minimum number of Cassandra nodes required to
achieve Quorum consensus is 4 I wonder why not 3? In fact, many container
deployments by default seem to deploy 4 nodes. Can anyone shine some light
on this?
What happens if I have 3 nodes and replication factor of 3 and consist
>
> Though in general I would say that it is worth considering. In
> particular if you have certain data that is accessed a lot more
> frequently than other data (especially if the "other data" is large),
> the improved cache locality of keeping the frequently accessed data
> separate can be high (
>> 4. ) Does the larger no of column families has any impact on the
>> performance(I read about it somewhere)? Should information for a particular
>> row key be split in multiple column families according to the specific query
>> demands or should all data related to a particular row key be kept to
>
> 1. ) If certain columns in a row get mutated too frequently or if new
> columns are added to the row frequently then does the reads of old columns
> that rarely get changed is also affected ? In other words, is the
> performance of reads of almost infrequently changing columns in a row where
>
1. ) If certain columns in a row get mutated too frequently or if new
columns are added to the row frequently then does the reads of old columns
that rarely get changed is also affected ? In other words, is the
performance of reads of almost infrequently changing columns in a row where
some columns
11 matches
Mail list logo
