cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleksandr Shulgin <oleksandr.shul...@zalando.de>
Subject Re: Cannot achieve consistency level LOCAL_ONE
Date Wed, 14 Jun 2017 09:09:04 GMT
On Wed, Jun 14, 2017 at 10:46 AM, wxn002@zjqunshuo.com <wxn002@zjqunshuo.com
> wrote:

> Thanks for the reply.
> My system_auth settings is as below and what should I do with it? And I'm
> interested why the newly added node is responsible for the user
> authentication?
>
> CREATE KEYSPACE system_auth WITH replication = {'class': '
> SimpleStrategy', 'replication_factor': '1'}  AND durable_writes = true;
>

You should change the replication options to use NetworkTopologyStrategy
and a replication factor greater than 1 in each DC.  It is not uncommon to
set it to the number of nodes in the DC, and is actually recommended by the
following piece of documentation:

http://docs.datastax.com/en/cassandra/2.1/cassandra/security/security_config_native_authenticate_t.html

For version 3, the official doc says to set it to 3-5 nodes per DC:
http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureConfigNativeAuth.html

In general there is no drawback when setting the RF for system_auth to the
number of nodes in DC, unless you're relying on the default superuser named
"cassandra" being able to login at all times.  This user is special and it
requires LOCAL_QUORUM in order to log in, while any other user (including
non-default superusers) require only LOCAL_ONE.

As to the reason why the new node is responsible for authenticating your
application user.  There is no particular reason for that.  The new node is
assigned a random set of tokens and it happened to be responsible for that
user, while some of the old nodes is no longer responsible (remember, you
have RF=1).

Hope this helps,
--
Alex

Mime
View raw message