You can do something like this, though your use of terminology like "queue"
really do not apply.
You can setup your keyspace with replication in only one data center.
CREATE KEYSPACE NTSkeyspace WITH REPLICATION = { 'class' :
'NetworkTopologyStrategy', 'dc2' : 3 };
This will make the NTSkeyspace like only in one data center. You can always
write to any Cassandra node, since they will transparently proxy the writes
to the proper place. You can configure your client to ONLY bind to specific
hosts or data centers/hosts DC1.
You can use a write consistency level like ANY. IF you use a consistency
level like ONE. It will cause the the write to block anyway waiting for
completion on the other datacenter.
Since you mentioned the words "like a queue" I would suggest an alternative
is to writing the data do a distributed commit log like kafka. At that
point you can decouple the write systems either through producer consumer
or through a tool like Kafka's mirror maker.
On Thu, Sep 29, 2016 at 5:24 PM, Dorian Hoxha <dorian.ho...@gmail.com>
wrote:
> I have dc1 and dc2.
> I want to keep a keyspace only on dc2.
> But I only have my app on dc1.
> And I want to write to dc1 (lower latency) which will not keep data
> locally but just push it to dc2.
> While reading will only work for dc2.
> Since my app is mostly write, my app ~will be faster while not having to
> deploy to the app to dc2 or write directly to dc2 with higher latency.
>
> dc1 would act like a queue or something and just push data + delete
> locally.
>
> Does this make sense ?
>
> Thank You
>
