>data would then start being siloed for recovery when the dc comes back Do we expect any degradation due to siloed data in the serving DC, such as higher latency due to SSTables remaining disjoint?
>I'm not sure why you'd do that, but it is possible A scenario in which an application wants strong consistency for a critical dataset (Keyspace1) and relaxed consistency for others (Keyspace2,3,...) Jaydeep On Sat, Nov 15, 2025 at 8:40 PM Blake Eggleston <[email protected]> wrote: > > > 1. With the "2 satellite configuration", the data will always remain > fully reconciled; in other words, there is no need to keep the data siloed. > Is that correct? > > Not quite. With the 2 satellite configuration, you can switch primaries > and there's no need to silo data because it's still talking to all > datacenters. However if there's a loss of a DC, or an outage that lasted > long enough, then you could disable the secondary satellite ( > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=399278313#CEP58:SatelliteDatacenters-Secondary/SatelliteDisableProcess) > and data would then start being siloed for recovery when the dc comes back. > > > 2. Can a Cassandra cluster have two tables coexist, one with a > primary/secondary concept and another active-active? > > > The replication is configured at the keyspace level, so two tables can't, > but 2 keyspaces could. Since it's just a replication setting, there > wouldn't be anything stopping you from doing things like having a DC that > is a satellite for one keyspace, a primary for another, and a secondary for > another. I'm not sure why you'd do that, but it is possible. >
