Bringing together the Apache Cassandra experts from the community and DataStax.

Want to learn? Have a question? Want to share your expertise? You are in the right place!

Not sure where to begin? Getting Started

 

question

mjcarey_178232 avatar image
mjcarey_178232 asked ·

Getting Unauthorized exception when creating a keyspace on the Astra CQL console

I tried the following in an attempt to create an Astra keyspace (in cqlsh) with fewer copies than three - but it didn't like it. Is there a way to do that? Just curious.

CREATE KEYSPACE norep WITH replication = {'class': 'NetworkTopologyStrategy', 'us-east-1': '1'} AND durable_writes = true;
Unauthorized: Error from server: code=2100 [Unauthorized] message="Missing correct permission on norep."
astra
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

1 Answer

Erick Ramirez avatar image
Erick Ramirez answered ·

It is not possible to configure the replica count to 1 because it breaks the guarantees that Cassandra provides for high availability. With 3 replicas in each DC, the application can tolerate an outage to a node with LOCAL_QUORUM consistency.

But if you look closely, the error isn't because you tried to create a keyspace with just 1 replica. It failed because you're not authorised to create keyspaces via cqlsh:

[Unauthorized] message="Missing correct permission on norep."

Creating keyspaces via the Astra CQL console is not allowed. Instead, you have to add a new keyspace through the Dashboard UI by clicking on the Add Keyspace button:

c11061-astra-add-keyspace.png

For details, see Managing multiple keyspaces on Astra. Cheers!


4 comments Share
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

My goal was to show students in a "Beyond SQL Data Management" class what sorts of things happen if you ask for more consistency (e.g., in a read or write request) than what the keyspace can currently deliver given the state of the system. So I was doing this on purpose, just for illustration. (Not a real use case.) If you happen to have ideas on how to show that in Astra-land, let me know - though I suspect the answer is that it's just not possible (by design), given the non-negotiable three-copies settings for Astra keyspaces and the available request-level consistency options. :-)

0 Likes 0 ·

Yes, I understand. However it is not possible to illustrate that with Astra -- the service is our opinionated view of how Cassandra clusters should be configured so there are guardrails in place which prevent users from configuring elements of the database that is not best practice. This is the reason it isn't possible to configure a keyspace with only 1 replica. Cheers!

0 Likes 0 ·

Got it - definitely a best practice. One last question about this thought, though: I would assume that Astra cloud developers may still want to build apps where different reads/writes want to use the three copies in different ways - i.e., they would still perhaps want to choose lower levels of read consistency or write consistency for less essential operations so that, in the event of one or two of their copies being down, they could still proceed. (E.g., add to cart vs. place order.) Is that not the case for Astra? And if it is the case, perhaps there should still be a way to do what I was hoping to try - otherwise, how can developers test that their availability choices are actually working?

0 Likes 0 ·

Unfortunately, no. In our opinion, there is a very limited use case for not using LOCAL_QUORUM consistency and 3 replicas in each DC. This is something we've been recommending for the last 10 years so Astra doesn't allow users to deviate from that.

I do understand that you want to show your students what happens when they've configured it wrong. Cheers!

0 Likes 0 ·