apache/cassandra · warning · IllegalStateException

Non-system keyspaces don't have the same replication setting

Error message

Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless

What it means

The all-keyspaces ownership report (effectiveOwnership with null/default keyspace) requires every user keyspace to share the same replication settings; otherwise summing per-node ownership across keyspaces yields misleading numbers. If any two user keyspaces differ (different class or RF), it throws IllegalStateException.

Source

Thrown at src/java/org/apache/cassandra/service/StorageService.java:4282

                throw new IllegalStateException("Ownership values for keyspaces with LocalStrategy are meaningless");

            strategy = keyspaceInstance.replicationStrategy;
            replicationParams = keyspaceInstance.params.replication;
        }
        else
        {
            Set<String> userKeyspaces = metadata.schema.getKeyspaces()
                                                       .without(SchemaConstants.REPLICATED_SYSTEM_KEYSPACE_NAMES)
                                                       .names();

            if (userKeyspaces.size() > 0)
            {
                keyspace = userKeyspaces.iterator().next();
                AbstractReplicationStrategy replicationStrategy = Schema.instance.getKeyspaceInstance(keyspace).getReplicationStrategy();
                for (String keyspaceName : userKeyspaces)
                {
                    if (!Schema.instance.getKeyspaceInstance(keyspaceName).getReplicationStrategy().hasSameSettings(replicationStrategy))
                        throw new IllegalStateException("Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless");
                }
            }

            if (keyspace == null)
            {
                keyspace = "system_traces";
            }

            Keyspace keyspaceInstance = Schema.instance.getKeyspaceInstance(keyspace);
            if (keyspaceInstance == null)
                throw new IllegalStateException("The node does not have " + keyspace + " yet, probably still bootstrapping. Effective ownership information is meaningless.");
            replicationParams = keyspaceInstance.getMetadata().params.replication;
            strategy = keyspaceInstance.getReplicationStrategy();
        }

        if (replicationParams.isMeta())
        {
            LinkedHashMap<InetAddressAndPort, Float> ownership = Maps.newLinkedHashMap();

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Pass an explicit keyspace to the ownership command so only that keyspace is analyzed
Unify replication settings across user keyspaces if a cluster-wide report is genuinely needed
Run per-keyspace ownership queries and aggregate externally
Recheck strategy class and RF for all keyspaces: cqlsh -e 'DESCRIBE KEYSPACES;'

Example fix

// before
nodetool ownership  # mixed strategies -> meaningless
// after
nodetool ownership my_keyspace

Defensive patterns

Strategy: try-catch

Validate before calling

Set<String> strategies = userKeyspaces.stream()
    .map(ks -> Schema.instance.getKeyspaceInstance(ks).getReplicationStrategy().getClass().getName() + "/RF")
    .collect(Collectors.toSet());
if (strategies.size() > 1) throw new IllegalArgumentException("mixed replication; query per keyspace");

Try / catch

try { ss.effectiveOwnership(null); } catch (IllegalStateException e) { if (e.getMessage().contains("same replication settings")) { return userKeyspaces.stream().collect(toMap(k -> k, k -> ownership(k))); } throw e; }

Prevention

Pass an explicit keyspace to ownership commands on heterogeneous clusters
Keep replication settings uniform only if you rely on cluster-wide ownership reports
Aggregate per-keyspace ownership externally

When it happens

Trigger: Calling `nodetool ownership` / effectiveOwnership(null) when user keyspaces have mixed replication (e.g. one keyspace NetworkTopologyStrategy RF=3, another SimpleStrategy RF=1 or different DCs).

Common situations: Multi-tenant clusters where keyspaces intentionally have different replication; clusters created ad hoc by different teams; after migrating a keyspace from SimpleStrategy to NetworkTopologyStrategy.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/0998cb048ca88371. Report an issue: GitHub.