Re: Restoring all cluster from snapshots
Hi, Not sure why this isn't working. Some thoughts, just in case: - Have you check the files rights / owner ? - Have you tried copying files after directory creation through your cqlsh -f schema step ? - Have you tried without setting tokens manually ? - Are you sure to put the right sstables at the right place (if # nodes prod or RF are different from production) ? - Is trying to use sstableloader an option you want to consider ? Good luck, C*heers, Alain 2015-06-09 15:32 GMT+02:00 Anton Koshevoy nowa...@gmail.com: Ok, new sequence: …. - rm -rf /db/cassandra/cr/data0*/system/* - /etc/init.d/cassandra start - cqlsh -f schema(here is the schema for cr_production keyspace only) - /etc/init.d/cassandra restart I see the new keyspace, but it’s empty: cqlsh describe keyspaces; system_traces cr_production system cqlsh use cr_production ; cqlsh:cr_production select * from cr_production.url_cs ; id | ct | d_id +-+--- (0 rows) = Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens OwnsHost ID Rack UN 10.40.231.3 74.35 KB 256 ? 7fc4f832-9d98-4bfd-81fb-0c361bff487d RACK01 UN 10.40.231.31 86.46 KB 256 ? 782d450d-50d5-4738-a654-bf7398557842 RACK01 Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless then I tried: - nodetool refresh -- cr_production url_cs with the same result. On June 9, 2015 at 1:29:36 AM, Robert Coli (rc...@eventbrite.com) wrote: On Mon, Jun 8, 2015 at 2:52 PM, Sanjay Baronia sanjay.baro...@triliodata.com wrote: Yes, you shouldn’t delete the system directory. Next steps are …reconfigure the test cluster with new IP addresses, clear the gossiping information and then boot the test cluster. If you don't delete the system directory, you run the risk of the test cluster nodes joining the source cluster. Just start a single node on the new cluster, empty, and create the schema on it. Then do the rest of the process. =Rob
Re: Restoring all cluster from snapshots
On Tue, Jun 9, 2015 at 6:32 AM, Anton Koshevoy nowa...@gmail.com wrote: - /etc/init.d/cassandra restart Cassandra reads and makes live any files it finds in its data directory. If you write to the keyspace and flush, is it flushing the new file in the directory you've put your sstable in? Permissions? =Rob
Re: Restoring all cluster from snapshots
Ok, new sequence: …. - rm -rf /db/cassandra/cr/data0*/system/* - /etc/init.d/cassandra start - cqlsh -f schema(here is the schema for cr_production keyspace only) - /etc/init.d/cassandra restart I see the new keyspace, but it’s empty: cqlsh describe keyspaces; system_traces cr_production system cqlsh use cr_production ; cqlsh:cr_production select * from cr_production.url_cs ; id | ct | d_id +-+--- (0 rows) = Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.40.231.3 74.35 KB 256 ? 7fc4f832-9d98-4bfd-81fb-0c361bff487d RACK01 UN 10.40.231.31 86.46 KB 256 ? 782d450d-50d5-4738-a654-bf7398557842 RACK01 Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless then I tried: - nodetool refresh -- cr_production url_cs with the same result. On June 9, 2015 at 1:29:36 AM, Robert Coli (rc...@eventbrite.com) wrote: On Mon, Jun 8, 2015 at 2:52 PM, Sanjay Baronia sanjay.baro...@triliodata.com wrote: Yes, you shouldn’t delete the system directory. Next steps are …reconfigure the test cluster with new IP addresses, clear the gossiping information and then boot the test cluster. If you don't delete the system directory, you run the risk of the test cluster nodes joining the source cluster. Just start a single node on the new cluster, empty, and create the schema on it. Then do the rest of the process. =Rob
Re: Restoring all cluster from snapshots
On Mon, Jun 8, 2015 at 6:22 AM, Anton Koshevoy nowa...@gmail.com wrote: - sudo rm -rf /db/cassandra/cr/data0*/system/* This removes the schema. You can't load SSTables for column families which don't exist. =Rob
Re: Restoring all cluster from snapshots
Rob, thanks for the answer. I just follow instruction from http://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_snapshot_restore_new_cluster.html If not to remove system table data, the test cluster starts interfering to a production cluster. How Can I avoid this situation? On June 8, 2015 at 9:48:30 PM, Robert Coli (rc...@eventbrite.com) wrote: On Mon, Jun 8, 2015 at 6:22 AM, Anton Koshevoy nowa...@gmail.com wrote: - sudo rm -rf /db/cassandra/cr/data0*/system/* This removes the schema. You can't load SSTables for column families which don't exist. =Rob
RE: Restoring all cluster from snapshots
Yes, you shouldn’t delete the system directory. Next steps are …reconfigure the test cluster with new IP addresses, clear the gossiping information and then boot the test cluster. If you are running Cassandra on VMware, then you may also want to look at this solutionhttp://www.triliodata.com/wp-content/uploads/2015/04/Cassandra-Trilio-Data-Sheet4.pdf from Trilio Data, where you can create a Cassandra backup and restore it to a Test Cluster. Regards, Sanjay _ Sanjay Baronia VP of Product Solutions Management TrilioData (c) 508-335-2306 sanjay.baro...@triliodata.commailto:sanjay.baro...@triliodata.com [Trilio-Business Assurance_300 Pixels]http://www.triliodata.com/ Experience Trilio in action, please click heremailto:i...@triliodata.com?subject=Demo%20Request. to request a demo today! From: Anton Koshevoy [mailto:nowa...@gmail.com] Sent: Monday, June 8, 2015 4:42 PM To: user@cassandra.apache.org Subject: Re: Restoring all cluster from snapshots Rob, thanks for the answer. I just follow instruction from http://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_snapshot_restore_new_cluster.html If not to remove system table data, the test cluster starts interfering to a production cluster. How Can I avoid this situation? On June 8, 2015 at 9:48:30 PM, Robert Coli (rc...@eventbrite.commailto:rc...@eventbrite.com) wrote: On Mon, Jun 8, 2015 at 6:22 AM, Anton Koshevoy nowa...@gmail.commailto:nowa...@gmail.com wrote: - sudo rm -rf /db/cassandra/cr/data0*/system/* This removes the schema. You can't load SSTables for column families which don't exist. =Rob
Re: Restoring all cluster from snapshots
I think you just have to do a DESC KEYSPACE mykeyspace; from one node of the production cluster then copy the output and import it in your dev cluster using cqlsh -f output.cql. Take care at the start of the output you might want to change DC names, RF or strategy. Also, if you don't want to restart nodes you can load data by using nodetool refresh mykeyspace mycf C*heers Alain 2015-06-08 22:42 GMT+02:00 Anton Koshevoy nowa...@gmail.com: Rob, thanks for the answer. I just follow instruction from http://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_snapshot_restore_new_cluster.html If not to remove system table data, the test cluster starts interfering to a production cluster. How Can I avoid this situation? On June 8, 2015 at 9:48:30 PM, Robert Coli (rc...@eventbrite.com) wrote: On Mon, Jun 8, 2015 at 6:22 AM, Anton Koshevoy nowa...@gmail.com wrote: - sudo rm -rf /db/cassandra/cr/data0*/system/* This removes the schema. You can't load SSTables for column families which don't exist. =Rob
Re: Restoring all cluster from snapshots
On Mon, Jun 8, 2015 at 2:52 PM, Sanjay Baronia sanjay.baro...@triliodata.com wrote: Yes, you shouldn’t delete the system directory. Next steps are …reconfigure the test cluster with new IP addresses, clear the gossiping information and then boot the test cluster. If you don't delete the system directory, you run the risk of the test cluster nodes joining the source cluster. Just start a single node on the new cluster, empty, and create the schema on it. Then do the rest of the process. =Rob
