Hi Yabin/Alain,
I changed the replication strategies for system_distributed, system_auth
and system_traces to use NetworkTopologyStrategies and repaired the
affected keyspaces. Now the rebuild process starts up ok without errors.
Thanks a lot for your help!
Best regards,
Timo
On 22 September 20
It is a Cassandra bug. The workaround is to change system_distributed
keyspce replication strategy to something as below:
alter keyspace system_distributed with replication = {'class':
'NetworkTopologyStrategy', 'DC1': '3', 'DC2': '3', 'DC3': '3'};
You may see similar problem for other sys
Hi Alain,
Our normal user keyspaces have RF3 in all DCs, e.g:
create keyspace reporting with replication = {'class':
'NetworkTopologyStrategy', 'DC1': '3', 'DC2': '3', 'DC3': '3'};
Any idea would it be safe to change the system_distributed keyspace to
match this?
-Timo
On 22 September 2016 at
Hi Alain,
Thanks a lot for a helping out!
Some of the basic keyspace / cluster info you requested:
# echo "DESCRIBE KEYSPACE system_distributed;" | cqlsh
CREATE KEYSPACE system_distributed WITH replication = {'class':
'SimpleStrategy', 'replication_factor': '3'} AND durable_writes = true;
CRE
It could be a bug.
Yet I am not very aware of this system_distributed keyspace, but from what
I see, it is using a simple strategy:
root@tlp-cassandra-2:~# echo "DESCRIBE KEYSPACE system_distributed;" |
cqlsh $(hostname -I | awk '{print $1}')
CREATE KEYSPACE system_distributed WITH replication =
Hi,
We have a Cassandra 3.0.8 cluster (recently upgraded from 2.1.15) currently
running in two data centers (13 and 19 nodes, RF3 in both). We are adding a
third data center before decommissioning one of the earlier ones.
Installing Cassandra (3.0.8) goes fine and all the nodes join the cluster
(n