Thanks Edward. Looks like it's not possible what I really wanted (to use
some kind of a quorum write ex).
Note that the queue is ordered, but I need just so they eventually happen,
but with more consistency than ANY (2 nodes or more).
On Fri, Sep 30, 2016 at 12:25 AM, Edward Capriolo <edlinuxg...@gmail.com>
wrote:
> 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
>>
>
>
