the volume of data is pretty low + you still want to be able to authenticate even if you have more nodes down than the RF for other keyspaces. Essentially you don't want auth to be the thing that stops you serving requests.
On Wed, 18 Jan 2017 at 14:57 Jai Bheemsen Rao Dhanwada < jaibheem...@gmail.com> wrote: > Thanks Ben, > > RF 3 isn't sufficient for system_auth? as we are using 3 RF for other > production KS, do you see any challenges? > > On Wed, Jan 18, 2017 at 2:39 PM, Ben Bromhead <b...@instaclustr.com> wrote: > > We have a process that syncs and manages RF==N and we also control and > manage users, however that entails it's own set of challenges and > maintenance. > > For most users I would suggest 3 < RF <=5 is sufficient. Also make sure > you don't use the user "Cassandra" in production as authentication queries > are done at QUORUM. > > On Wed, 18 Jan 2017 at 13:41 Jai Bheemsen Rao Dhanwada < > jaibheem...@gmail.com> wrote: > > Hello, > > When enabling Authentication on cassandra, is it required to set the RF > same as the no.of nodes( > https://docs.datastax.com/en/cql/3.1/cql/cql_using/update_ks_rf_t.html)? > or can I live with RF of 3 in each DC (other KS are using 3) > > If it has to be equal to the number of nodes then, every time adding or > removing a node requires update of RF. > > Thanks in advance. > > -- > Ben Bromhead > CTO | Instaclustr <https://www.instaclustr.com/> > +1 650 284 9692 <+1%20650-284-9692> > Managed Cassandra / Spark on AWS, Azure and Softlayer > > > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Managed Cassandra / Spark on AWS, Azure and Softlayer
