It was my mistake. Before I checked the trace I assume it meant the data
also had been replicated to the remote cluster, which is why it could
answer the request. Thank you for responding so quickly and helping correct
my misunderstanding. As long as the data isn't being replicated, everything
else
That’s the behaviour I would have expected. I’m not aware of anyway to
prevent this and would be surprised if there is one (but I’ve never tried
to find one either so it might be possible).
Cheers
Ben
On Fri, 17 Jun 2016 at 12:02 Jason J. W. Williams
wrote:
> Hey Ben,
>
> Looks like just the sc
Hey Ben,
Looks like just the schema. I was surprised that running SELECTs against
the DC which should not have any data (because it's not specified in
NetworkTopologyStrategy), actually returned data. But looking at the query
trace it looks like its forwarding the queries to the other DC.
-J
On
Do you mean the data is getting replicated or just the schema?
On Fri, 17 Jun 2016 at 11:48 Jason J. W. Williams
wrote:
> Hi Guys,
>
> We have a 2 DC cluster where the keyspaces are replicated between the 2.
> Is it possible to add a keyspace to one of the DCs that won't be replicated
> to the o
Hi Guys,
We have a 2 DC cluster where the keyspaces are replicated between the 2. Is
it possible to add a keyspace to one of the DCs that won't be replicated to
the other?
Whenever we add a new keyspace it seems to get replicated even if we don't
specify the other DC in the keyspace's NetworkTopo
