in cassandra-env.sh
>
> fe80\:0\:0\:0\:202\:b3ff\: fe1e\:8329=DC1:RAC3
>
>
>
>
> On Tuesday, June 19, 2018, 12:51:34 PM EDT, Durity, Sean R <
> sean_r_dur...@homedepot.com> wrote:
>
>
> You are correct that the cluster decides where data goes (based on the
> has
imbalance in the
“first” node of the rack.
To help you more, we would need the create table statement(s) for your keyspace
and the topology of the cluster (like with nodetool status).
Sean Durity
From: learner dba
Sent: Tuesday, June 19, 2018 9:50 AM
To: user@cassandra.apach
key). However, if you choose a “bad” partition key,
> you may not get good distribution of the data, because the hash is
> deterministic (it always goes to the same nodes/replicas). For example, if
> you have a partition key of a datetime, it is possible that there is more
> data written
tement(s) for your keyspace
and the topology of the cluster (like with nodetool status).
Sean Durity
From: learner dba
Sent: Tuesday, June 19, 2018 9:50 AM
To: user@cassandra.apache.org
Subject: Re: RE: [EXTERNAL] Cluster is unbalanced
We do not chose the node where partition wil
CREATE KEYSPACE data WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': '3', 'dc2': '3'} AND durable_writes = true;
cqlsh> select * from system_schema.keyspaces ;
keyspace_name | durable_writes | replication
++
what is your keyspace configuration. Do you have all the keyspaces
configured for both DCs?
can you run below query from cqlsh and see if the keyspace is configured to
use both DCs
select * from system.schema_keyspaces; # if your cluster is on 2.1 or less
select * from system_schema.keyspaces
on of the data, because the hash is
> deterministic (it always goes to the same nodes/replicas). For example, if
> you have a partition key of a datetime, it is possible that there is more
> data written for a certain time period – thus a larger partition and an
> imbalance across the
important decisions for a Cassandra
table.
Also, I have seen the use of racks in the topology cause an imbalance in the
“first” node of the rack.
To help you more, we would need the create table statement(s) for your keyspace
and the topology of the cluster (like with nodetool stat
@cassandra.apache.org
Subject: Re: RE: [EXTERNAL] Cluster is unbalanced
We do not chose the node where partition will go. I thought it is snitch's role
to chose replica nodes. Even the partition size does not vary on our largest
column family:
Percentile SSTables Write Latency Read La
C*) rings (Staff Systems Engineer – Cassandra)
MTC 2250
#cassandra - for the latest news and updates
From: learner dba
Sent: Monday, June 18, 2018 2:06 PM
To: User cassandra.apache.org
Subject: [EXTERNAL] Cluster is unbalanced
Hi,
Data volume varies a lot in our two DC clu
ivide up as cleanly as you would
> like across the cluster because the data is not evenly distributed (by
> partition key)?
>
>
>
>
>
> Sean Durity
>
> lord of the (C*) rings (Staff Systems Engineer – Cassandra)
>
> MTC 2250
>
> #cassandra - for the latest new
rtition
key)?
Sean Durity
lord of the (C*) rings (Staff Systems Engineer – Cassandra)
MTC 2250
#cassandra - for the latest news and updates
From: learner dba
Sent: Monday, June 18, 2018 2:06 PM
To: User cassandra.apache.org
Subject: [EXTERNAL] Cluster is unbalanced
Hi,
Engineer – Cassandra)
MTC 2250
#cassandra - for the latest news and updates
From: learner dba
Sent: Monday, June 18, 2018 2:06 PM
To: User cassandra.apache.org
Subject: [EXTERNAL] Cluster is unbalanced
Hi,
Data volume varies a lot in our two DC cluster:
Load Tokens Owns
20.01 GiB 256
Hi,
Data volume varies a lot in our two DC cluster:
Load Tokens Owns
20.01 GiB 256 ?
65.32 GiB 256 ?
60.09 GiB 256 ?
46.95 GiB 256 ?
50.73 GiB 256 ?
kaiprodv2
=
/Leaving/Joining/Moving
14 matches
Mail list logo
