One trick could be :
Before enabling authorization
1. Give user1 superuser permission temporarily by logging in with
cassandra suer
ALTER ROLE user1 with SUPERUSER=true;
2. Enable authorization and grant permission to user1 for specific operation
GRANT SELECT ON ALL KEYSPACES TO user1;
Hi , our application is running in to data corruption issue. Application
uses cassandra 2.1.11 with datastax java driver version 2.1.9. So far all
working fine. recently we changed our deployment environment to openjdk
1.7.191 (earlier it was 1.7.181) and centos 7.4 (earlier 6.8) This is
randomly
Hi Chris,
Funny you mention this today of all days because we're doing a twitch
streaming session in a few hours on this very topic with Adron from our
dev-rel team.
The short answer is yes it works. Here's the example project we're working
on that uses GraalVM via quarkus.io:
Do you have compression enabled on your table?
Did this start with the JDK upgrade?
Is the compression spreading, or is it contained to the same % of entries?
On Thu, May 9, 2019 at 4:12 AM keshava wrote:
> Hi , our application is running in to data corruption issue. Application
> uses
Hope you find those helpful :)
If you missed us, these things are recorded
https://www.twitch.tv/datastaxacademy/videos
All the best,
Sebastián Estévez | Vanguard Solution Architect
Mobile +1.954.905.8615
sebastian.este...@datastax.com | datastax.com
Hello team,
I am observing below warn and info message in system.log
1. Info log: maximum memory usage reached (1.000GiB), cannot allocate chunk
of 1 MiB.
I tried by increasing the file_cache_size_in_mb in Cassandra.yaml from 512
to 1024. But still this message shows up in logs.
2. Warn log:
Awesome. Will try to join.
Thanks for the links. Will look through them also.
On Thu, May 9, 2019 at 8:33 AM Sebastian Estevez <
sebastian.este...@datastax.com> wrote:
> Hi Chris,
>
> Funny you mention this today of all days because we're doing a twitch
> streaming session in a few hours on
maybe print out value into the logfile and that should lead to some
clue where it might be the problem?
On Tue, May 7, 2019 at 4:58 PM Paul Chandler wrote:
>
> Roy, We spent along time trying to fix it, but didn’t find a solution, it was
> a test cluster, so we ended up rebuilding the cluster,
I think you will get below exception while executing GRANT with
AllowAllAuthorizer
ServerError: java.lang.UnsupportedOperationException: GRANT operation is
not supported by AllowAllAuthorizer
On Thu, May 9, 2019 at 12:07 PM Devaki, Srinivas
wrote:
> Hi,
>
> before changing the configuration
I am doing post-mortem on an issue with our cassandra cluster. One of our
tables became corrupt and had to be restored via a backup. The table
schema has been undergoing active development, so the number of "alter
table" statements was quite large (300+). Currently, we use cqlsh to do
schema
yes we do have compression enabled using
"org.apache.cassandra.io.compress.LZ4Compressor" it is spreading..
as the no of inserts increases it is spreading across.
yes it did started with JDK and OS upgrade.
Best regards :)
keshava Hosahalli
On Thu, May 9, 2019 at 7:11 PM Jeff Jirsa wrote:
>
Let's say I have a 3 node cluster on 3.11.4 on which authentication is
enabled but authorization is disabled. It has one non-super login user
'user1' and default super user 'cassandra'
In cassandra.yaml
authenticator: PasswordAuthenticator
authorizer: AllowAllAuthorizer
So to enable
Hi,
before changing the configuration from `AllowAllAuthorizer` to
`CassandraAuthorizer`, you need to grant enough permissions to the user
that allow all the accessed tables by that user. I think that should fix
the problem.
Thanks
On Thu, May 9, 2019 at 12:02 PM Laxmikant Upadhyay
wrote:
>
13 matches
Mail list logo
