PLANNED MAINTENANCE

Hello, DataStax Community!

We want to make you aware of a few operational updates which will be carried out on the site. We are working hard to streamline the login process to integrate with other DataStax resources. As such, you will soon be prompted to update your password. Please note that your username will remain the same.

As we work to improve your user experience, please be aware that login to the DataStax Community will be unavailable for a few hours on:

  • Wednesday, July 15 16:00 PDT | 19:00 EDT | 20:00 BRT
  • Thursday, July 16 00:00 BST | 01:00 CEST | 04:30 IST | 07:00 CST | 09:00 AEST

For more info, check out the FAQ page. Thank you for being a valued member of our community.


question

igor.rmarinho_185445 avatar image
igor.rmarinho_185445 asked ·

Is it possible to lock the Consistency at DB level?

Hi,

Is it possible to lock the Consistency at DB level? Since when we set it on cqlsh it lasts only the time the session is alive.


Thanks


consistency
1 comment
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.

@igor.rmarinho_185445, could you elaborate your question a little bit more? Feel free to add additional information on the original question by editing it. Are you looking to implement a default consistency level for CQLSH sessions or for your applications connecting to Cassandra using various drivers? Also, could you please mention which version of Cassandra/DataStax Enterprise (DSE) are you using?

0 Likes 0 · ·

1 Answer

Erick Ramirez avatar image
Erick Ramirez answered ·

@igor.rmarinho_185445 As you know at the server level the default consistency is ONE. It is not possible to change this default server-side because it prefers availability over consistency.

You can set it globally for the life of your session but typically when you're using cqlsh, you're most likely making schema changes in which case all nodes need to be up and operational. Otherwise, you're likely doing some tests or trying things out so you're really taking advantage of the tunable consistency and decide what you want based on what you're testing.

For example, if you're troubleshooting inconsistent results for a specific query then it makes sense to use LOCAL_ONE so you can test the state of a specific replica. If however you're trying to trigger a read-repair, then you have to set a consistency of ALL.

Specifically with cqlsh (or DataStax Studio), my personal opinion is that it doesn't make sense to have the consistency set server-side since you're using those clients for a specific reason. On the application-side, it is best-practice to set a global consistency for both reads and writes.

If you're interested, there is additional info on tunable consistency here. Cheers!

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.