Hey Cassandra folks,
I'm trying to change the schema of an existing table by creating a new one
and migrating the data.
The initial table schema looks like this:
*CREATE TABLE IF NOT EXISTS initial_table (user_id
text,message_id timeuuid,interaction_state
text,i
Hi Bogdan,
First - I am probably captain obvious here - but you will lose some data in
the process. as *interaction_timestamp *is not part of the primary key
anymore you will upsert the new row multiple times, last one win.
The CSV rows are loaded in parallel with multiple threads and multiple
c
A caveat to the 31GB recommendation for G1GC. If you have tight latency SLAs
instead of throughput SLAs then this doesn’t necessary pan out to be beneficial.
Yes the GCs are less frequent, but they can hurt more when they do happen. The
win is if your usage pattern is such that the added time h
We are using G1 ...
On Tue, 11 Feb 2020 at 08:51, Reid Pinchback
wrote:
> A caveat to the 31GB recommendation for G1GC. If you have tight latency
> SLAs instead of throughput SLAs then this doesn’t necessary pan out to be
> beneficial.
>
>
>
> Yes the GCs are less frequent, but they can hurt mo
Do you have any chance to take a look about this one?
Il giorno lun 3 feb 2020 alle ore 23:36 Sergio
ha scritto:
> After reading this
>
> *I would only consider moving a cluster to 4 tokens if it is larger than
> 100 nodes. If you read through the paper that Erick mentioned, written
> by Joe Lyn
Hello,
I have Cassandra cluster(2.1.16) where the application is using the legacy
thrift schema (Cassandra-cli). I am planning to upgrade the cluster to
3.11.X without changing the schema. but the new 3.x doesn't have
cassandra-cli utilities. is there any alternative to get the cli installed
on 3.
>
> I am seeing some unbalancing and I was worried because I have 256 vnodes
> Weird stuff is related to this post where I don't find a match between the
> load and du -sh * for the node 10.1.31.60 and I was trying to figure out
> the reason, if it was due to the number of vnodes.
Out of curiosit
Jai, Thrift was deprecated years ago (maybe 5 or 6?) and COMPACT STORAGE
was dropped since the refactor of the storage engine in C* 3.0 so there
won't be support for any legacy CLI. In fact, you need to migrate off
legacy storage when you upgrade using ALTER TABLE ks.table DROP COMPACT
STORAGE.
Yo
I am using astyanax client
On Tuesday, February 11, 2020, Erick Ramirez
wrote:
> Jai, Thrift was deprecated years ago (maybe 5 or 6?) and COMPACT STORAGE
> was dropped since the refactor of the storage engine in C* 3.0 so there
> won't be support for any legacy CLI. In fact, you need to migrate
>
> I am using astyanax client
Right. It was announced as being retired back in 2016 [1] which ended in
2018 [2]:
>
> *DeprecationAstyanax has been retired and is no longer under active
> development but may receive dependency updates to ease migration away from
> Astyanax.In place of Astyanax
10 matches
Mail list logo
