Re: Do I need to run repair and compaction every node?
Just read the source and well… yup. I’m guessing now that the options are indeed only rolling repair on each node (with -pr stopping the duplicate work) or -st -9223372036854775808 -et 9223372036854775807 to actually cover all ranges. I didn’t walk through to test that, though. Glad 3.0 is getting a little bit of love on improving repairs and communications / logging about them. -Jeff On Apr 13, 2015, at 3:45 PM, Robert Coli rc...@eventbrite.com wrote: On Mon, Apr 13, 2015 at 3:33 PM, Jeff Ferland j...@tubularlabs.com mailto:j...@tubularlabs.com wrote: Nodetool repair -par: covers all nodes, computes merkle trees for each node at the same time. Much higher IO load as every copy of a key range is scanned at once. Can be totally OK with SSDs and throughput limits. Only need to run the command one node. No? -par is just a performance (of repair) de-optimization, intended to improve service time during repair. Doing -par without -pr on a single node doesn't repair your entire cluster. Consider the following 7 node cluster, without vnodes : A B C D E F G RF=3 You run a repair on node D, without -pr. D is repaired against B's tertiary replicas. D is repaired against C's secondary replicas. E is repaired against D's secondary replicas. F is repaired against D's tertiary replicas. Nodes A and G are completely unaffected and unrepaired, because D does not share any ranges with them. repair with or without -par only covers all *replica* nodes. Even with vnodes, you still have to run it on almost all nodes in most cases. Which is why most users should save themselves the complexity and just do a rolling -par -pr on all nodes, one by one. =Rob
Data migration
Hello!!! Need to migrate data from one C* cluster to another periodically. During migration schema can change(add or remove one, two fields). Could you please suggest some tool?
Re: Do I need to run repair and compaction every node?
On Mon, Apr 13, 2015 at 11:43 PM, Jeff Ferland j...@tubularlabs.com wrote: Just read the source and well… yup. I’m guessing now that the options are indeed only rolling repair on each node (with -pr stopping the duplicate work) or -st -9223372036854775808 -et 9223372036854775807 to actually cover all ranges. I didn’t walk through to test that, though. Technically speaking, in the non-vnode world, you can just run a non-pr repair on certain nodes and repair 100% of the cluster. A B C D E F G H I N=8 RF=3 Without -pr, if you repair C (repairs A,B,D,E) and G (repairs E,F,H,I)... you're done. Vnodes makes this sort of thing too complex to bother with, with the chance that all physical nodes share at least one range with other nodes being quite high. Glad 3.0 is getting a little bit of love on improving repairs and communications / logging about them. +1 =Rob
Re: Drawbacks of Major Compaction now that Automatic Tombstone Compaction Exists
Hi Robert, By automatic tombstone compaction, I am referring to tombstone_threshold sub property under compaction strategy in CQL. It is 0.2 by default. So what I understand from the Datastax documentation is that even if a sstable does not find sstables of similar size (STCS) , an automatic tombstone compaction will trigger on sstable when 20% data is tombstone. This compaction works on single sstable only. How Major compaction is related to automatic tombstone compaction? Earlier we used to say that Major compaction is not recommended because one huge sstable formed after Major compaction will not find any similar size sstables unless huge data is written in new sstables and thus tombstones will be there in the huge sstable unnnecessarily for long time. My understanding is that automatic tombstone compaction will allow tombstone collection on huge sstable formed after major compaction and that should no more be considered a drawback. Please confirm my understanding. Also I want to know are there any other side effects and inefficiences of say 100+ gb sstable? Please refer to my fist email on the issue. We tried splitting sstable using sstablesplit but just because all small sstables are generated of same size, STCS compacted them back to single giant sstable as soon as we started Cassandra. Any other alternatives ? JIRA for the Issue of numerous tiny sstables being generated after repair is still open and we want a confirmation that if we face such issue in prod we can go ahead with one time major compaction. Thanks Anuj Wadehra From:Robert Coli rc...@eventbrite.com Date:Tue, 14 Apr, 2015 at 12:54 am Subject:Re: Drawbacks of Major Compaction now that Automatic Tombstone Compaction Exists On Mon, Apr 13, 2015 at 10:52 AM, Anuj Wadehra anujw_2...@yahoo.co.in wrote: Any comments on side effects of Major compaction especially when sstable generated is 100+ GB? I have no idea how this interacts with the automatic compaction stuff; if you find out, let us know? But if you want to do a major and don't want to deal with One Big SSTable afterwards, stop the node and then run sstable_split utility. =Rob
Re: Data migration
Look into sqoop. I believe using sqoop you can transfer data between C* clusters. I haven't tested it though. other option is to write a program to read from one cluster and write the required data to another. On Tue, Apr 14, 2015 at 12:27 PM, skrynnikov_m skrinniko...@epsysoft.com.ua wrote: Hello!!! Need to migrate data from one C* cluster to another periodically. During migration schema can change(add or remove one, two fields). Could you please suggest some tool?
Re: Data migration
Use SSTableloader it comes with Cassandra and is designed for moving data between clusters and is far simpler than sqoop. it should even work with a schema change like you described (changing columns). It would probably/definitely break if you were dropping tables. Mind you I've never tried sstableloader while schema changes were occurring so happy to be wrong. On 14 April 2015 at 05:40, Prem Yadav ipremya...@gmail.com wrote: Look into sqoop. I believe using sqoop you can transfer data between C* clusters. I haven't tested it though. other option is to write a program to read from one cluster and write the required data to another. On Tue, Apr 14, 2015 at 12:27 PM, skrynnikov_m skrinniko...@epsysoft.com.ua wrote: Hello!!! Need to migrate data from one C* cluster to another periodically. During migration schema can change(add or remove one, two fields). Could you please suggest some tool? -- Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr http://twitter.com/instaclustr | (650) 284 9692
