COPY command with where condition

Hello all, In my company we want to export a big dataset of our cassandra's ring. We search to use COPY command but I don't find if and how can a WHERE condition can be use ? Because we need to export only several data which must be return by a WHERE closure, specially and unfortunately with

Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names

Loader* https://www.datastax.com/blog/2018/05/introducing-datastax-bulk-loader On Fri, Jan 17, 2020, 09:09 Vova Shelgunov wrote: > DataStax bulk loaded can be an option if data is large. > > On Fri, Jan 17, 2020, 07:33 Nitan Kainth wrote: > >> If the keyspace already exist, use copy command

Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names

DataStax bulk loaded can be an option if data is large. On Fri, Jan 17, 2020, 07:33 Nitan Kainth wrote: > If the keyspace already exist, use copy command or sstableloader to merge > data. If data volume it too big, consider spark or a custom java program > > > Regards, > > Nitan > > Cell: 510

Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names

If the keyspace already exist, use copy command or sstableloader to merge data. If data volume it too big, consider spark or a custom java program Regards, Nitan Cell: 510 449 9629 > On Jan 16, 2020, at 10:26 PM, Ankit Gadhiya wrote: > >  > Any leads on this ? > > — Ankit > >> On Thu,

Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names

Any leads on this ? — Ankit On Thu, Jan 16, 2020 at 8:51 PM Ankit Gadhiya wrote: > Hi Arvinder, > > Thanks for your response. > > Yes - Cluster B already has some data. Tables/KS names are identical ; for > data - I still haven't got the clarity if it has identical data or no - I > am assuming

Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names

Hi Arvinder, Thanks for your response. Yes - Cluster B already has some data. Tables/KS names are identical ; for data - I still haven't got the clarity if it has identical data or no - I am assuming no since it's for different customers but need the confirmation. *Thanks & Regards,* *Ankit

Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names

So as I understand, Cluster B already has some data and not an empty cluster. When you say, clusters share same keyspace and table names, do you mean both clusters have identical data on those ks/tables? -Arvi On Thu, Jan 16, 2020, 5:27 PM Ankit Gadhiya wrote: > Hello Group, > > I have a

*URGENT* Migration across different Cassandra cluster few having same keyspace/table names

Hello Group, I have a requirement in one of the production systems where I need to be able to migrate entire dataset from Cluster A (Azure Region A) to Cluster B (Azure Region B). Each cluster have 3 Cassandra nodes (RF=3) running used by different applications. Few of the applications are

Unified DataStax drivers

Hi all, Last September, Jonathan Ellis announced at ApacheCon NA that DataStax was going to unify the drivers that we develop for Apache Cassandra and DataStax Enterprise into a single open-source, Apache v2.0 Licensed driver. Yesterday, we released this new

Re: How to assure data consistency in switch over to standby dc

On Thu, Jan 16, 2020 at 3:18 PM Laxmikant Upadhyay wrote: > > You are right, that will solve the problem. but unfortunately i won't be > able to meet my sla with write each quorum . I am using local quorum for > both read and write. > Any other way ? > Is you read SLO more sensitive than write

Re: How to assure data consistency in switch over to standby dc

Hello Laxmiant, your application has to deal with eventually consistency if you are using cassandra. Ensure to have R + W > RF And have the repairs runing periodically. This is the best way to be the most cosistent and coherent Jean Carlo "The best way to predict the future is to invent it"

Re: How to assure data consistency in switch over to standby dc

Hi Alex, You are right, that will solve the problem. but unfortunately i won't be able to meet my sla with write each quorum . I am using local quorum for both read and write. Any other way ? On Thu, Jan 16, 2020, 5:45 PM Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > On Thu, Jan

Re: How to assure data consistency in switch over to standby dc

On Thu, Jan 16, 2020 at 1:04 PM Laxmikant Upadhyay wrote: > Hi, > What I meant fromActive/standby model is that even though data is being > replicated (asynchronously) to standby DC , client will only access the > data from active DC (let's say using local_quorum). > > you have "to switch" your

Re: How to assure data consistency in switch over to standby dc

Hi, What I meant fromActive/standby model is that even though data is being replicated (asynchronously) to standby DC , client will only access the data from active DC (let's say using local_quorum). you have "to switch" your clients without any issues since your writes are replicated on all DC.

Re: How to assure data consistency in switch over to standby dc

Hello, What do you mean by active/standby model ? Cassandra is designed to be active/active inter DC. So you have "to switch" your clients without any issues since your writes are replicated on all DC. Unless you would mean by active/standby that the keyspace is not replicated on the second DC ?

How to assure data consistency in switch over to standby dc

We have 2 dc in active/standby model. At any given point if we want to switch to standby dc, how will we make sure that data is consistent with active site? Note that repair runs at its scheduled time. I am thinking of below approaches : 1.Before switching run the repair (although it assure