We did something similar with a split cloud/physical hardware deployment.
There was a weird requirement that app authentication data (fortunately in
it's own keyspace already) could not "live on the cloud" (shrug).
This ended up being a simple configuration change in the schema just like
your example and has, TMK, worked fine since.
On Fri, May 16, 2014 at 7:37 PM, Tupshin Harper <tups...@tupshin.com> wrote:
> It's often an excellent strategy. No known issues.
>
> -Tupshin
> On May 16, 2014 4:13 PM, "Anand Somani" <meatfor...@gmail.com> wrote:
>
>> Hi,
>>
>> It seems like it should be possible to have a keyspace replicated only to
>> a subset of DC's on a given cluster spanning across multiple DCs? Is there
>> anything bad about this approach?
>>
>> Scenario
>> Cluster spanning 4 DC's => CA, TX, NY, UT
>> Has multiple keyspaces such that
>> * "keyspace_CA_TX" - replication_strategy = {CA = 3, TX = 3}
>> * "keyspace_UT_NY" - replication_strategy = {UT = 3, NY = 3}
>> * "keyspace_CA_UT" - replication_strategy = {UT = 3, CA = 3}
>>
>> I am going to try this out, but was curious if anybody out there has
>> tried it.
>>
>> Thanks
>> Anand
>>
>
--
-----------------
Nate McCall
Austin, TX
@zznate
Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
