Re: Drop/Create table with same CF Name
You should not run a truncate until the whole ring is reporting "Up/Normal." If there is a lot of flapping and it's a critical situation, disable hinted handoff as well (and you may want to move phi_convict_threshold up to 16 as well temporarily). Stopping the compaction process temporarily on each node (it will restart as soon a memtable flushes again) has two positive effects for this case: - removes load and GC pressure - allows the truncate operation to complete fairly quick (as it is blocked by compaction) On Tue, May 26, 2015 at 8:33 AM, Ken Hancock wrote: > Nate, how does this get around the issue? I'm guessing that just extends > the timeout, but if I had a server failure such that the server was down > for a couple hours, truncate would still have issues? > > > > On Sat, May 23, 2015 at 5:46 PM, Nate McCall > wrote: > >> > >> > Truncate would have been the tool of choice, however my understanding >> is truncate fails unless all nodes are up and running which makes it a >> non-workable choice since we can't determine when failures will occur. >> > >> >> You can get around this via: >> - in cassandra.yaml, turning up "truncate_request_timeout_in_ms" to 10 >> minutes >> - stopping all compactions: nodetool stop >> [compaction|validation|cleanup|scrub|index_build] (that's 5 commands total) >> >> >> >> -- >> - >> Nate McCall >> Austin, TX >> @zznate >> >> Co-Founder & Sr. Technical Consultant >> Apache Cassandra Consulting >> http://www.thelastpickle.com >> > > > > > > -- - Nate McCall Austin, TX @zznate Co-Founder & Sr. Technical Consultant Apache Cassandra Consulting http://www.thelastpickle.com
Re: Drop/Create table with same CF Name
Nate, how does this get around the issue? I'm guessing that just extends the timeout, but if I had a server failure such that the server was down for a couple hours, truncate would still have issues? On Sat, May 23, 2015 at 5:46 PM, Nate McCall wrote: > > > > Truncate would have been the tool of choice, however my understanding is > truncate fails unless all nodes are up and running which makes it a > non-workable choice since we can't determine when failures will occur. > > > > You can get around this via: > - in cassandra.yaml, turning up "truncate_request_timeout_in_ms" to 10 > minutes > - stopping all compactions: nodetool stop > [compaction|validation|cleanup|scrub|index_build] (that's 5 commands total) > > > > -- > - > Nate McCall > Austin, TX > @zznate > > Co-Founder & Sr. Technical Consultant > Apache Cassandra Consulting > http://www.thelastpickle.com >
RE: Drop/Create table with same CF Name
Totally agree with this. From: Ken Hancock [mailto:ken.hanc...@schange.com] Sent: 22 May 2015 17:10 To: user@cassandra.apache.org Subject: Re: Drop/Create table with same CF Name This issue really needs to be strongly highlighted in the documentation. Imagine someone noticing similarities between SQL and CQL and assuming that one could actually drop a table and recreate the table as a method of deleting all the data...totally crazy, I know... On Fri, May 22, 2015 at 11:06 AM, Walsh, Stephen mailto:stephen.wa...@aspect.com>> wrote: Thanks for the link, I don’t think your link is what I hand mind – considering it mentioned to be fixed in 2.0.13 I was referring to this “won’t fix” issue https://issues.apache.org/jira/browse/CASSANDRA-4857 We’ve seen this a few times, we’re we drop a key space and re-create it and get inconstancy issues. It even happened to me mid Message thread on these boards. http://www.mail-archive.com/user%40cassandra.apache.org/msg42139.html From: Sebastian Estevez [mailto:sebastian.este...@datastax.com<mailto:sebastian.este...@datastax.com>] Sent: 22 May 2015 14:46 To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> Subject: Re: Drop/Create table with same CF Name I’m aware of issues where recreating key spaces can cause inconsistency in 2.0.13 if memTables are not flushed beforehand , is this the issues that is resolved? Yep, that's https://issues.apache.org/jira/browse/CASSANDRA-7511 All the best, [datastax_logo.png]<http://www.datastax.com/> Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com<mailto:sebastian.este...@datastax.com> [linkedin.png]<https://www.linkedin.com/company/datastax>[facebook.png]<https://www.facebook.com/datastax>[twitter.png]<https://twitter.com/datastax>[g+.png]<https://plus.google.com/+Datastax/about>[https://lh6.googleusercontent.com/24_538J0j5M0NHQx-jkRiV_IHrhsh-98hpi--Qz9b0-I4llvWuYI6LgiVJsul0AhxL0gMTOHgw3G0SvIXaT2C7fsKKa_DdQ2uOJ-bQ6h_mQ7k7iMybcR1dr1VhWgLMxcmg]<http://feeds.feedburner.com/datastax> [http://datastax.com/all/images/cs_logo_color_sm.png]<http://cassandrasummit-datastax.com/> DataStax is the fastest, most scalable distributed database technology, delivering Apache Cassandra to the world’s most innovative enterprises. Datastax is built to be agile, always-on, and predictably scalable to any size. With more than 500 customers in 45 countries, DataStax is the database technology and transactional backbone of choice for the worlds most innovative companies such as Netflix, Adobe, Intuit, and eBay. On Fri, May 22, 2015 at 7:53 AM, Walsh, Stephen mailto:stephen.wa...@aspect.com>> wrote: Can someone share the content on this link please, I’m aware of issues where recreating key spaces can cause inconsistency in 2.0.13 if memTables are not flushed beforehand , is this the issues that is resolved? From: Ken Hancock [mailto:ken.hanc...@schange.com<mailto:ken.hanc...@schange.com>] Sent: 21 May 2015 17:13 To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> Subject: Re: Drop/Create table with same CF Name Thanks Mark (though that article doesn't appear publicly accessible for others). Truncate would have been the tool of choice, however my understanding is truncate fails unless all nodes are up and running which makes it a non-workable choice since we can't determine when failures will occur. Ken On Thu, May 21, 2015 at 11:00 AM, Mark Reddy mailto:mark.l.re...@gmail.com>> wrote: Yes, it's a known issue. For more information on the topic see this support post from DataStax: https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 Mark On 21 May 2015 at 15:31, Ken Hancock mailto:ken.hanc...@schange.com>> wrote: We've been running into the reused key cache issue (CASSANDRA-5202) with dropping and recreating the same table in Cassandra 1.2.18 so we've been testing with key caches disabled which does not seem to solve the issue. In the latest logs it seems that old SSTables metadata gets read after the tables have been deleted by the previous drop, eventually causing an exception and the Thrift interface shut down. At this point is it a known issue that one CANNOT reuse a table name prior to Cassandra 2.1 ? This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments. This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have recei
Re: Drop/Create table with same CF Name
> > Truncate would have been the tool of choice, however my understanding is truncate fails unless all nodes are up and running which makes it a non-workable choice since we can't determine when failures will occur. > You can get around this via: - in cassandra.yaml, turning up "truncate_request_timeout_in_ms" to 10 minutes - stopping all compactions: nodetool stop [compaction|validation|cleanup|scrub|index_build] (that's 5 commands total) -- - Nate McCall Austin, TX @zznate Co-Founder & Sr. Technical Consultant Apache Cassandra Consulting http://www.thelastpickle.com
Re: Drop/Create table with same CF Name
This issue really needs to be strongly highlighted in the documentation. Imagine someone noticing similarities between SQL and CQL and assuming that one could actually drop a table and recreate the table as a method of deleting all the data...totally crazy, I know... On Fri, May 22, 2015 at 11:06 AM, Walsh, Stephen wrote: > Thanks for the link, > > > > I don’t think your link is what I hand mind – considering it mentioned to > be fixed in 2.0.13 > > > > I was referring to this “won’t fix” issue > > https://issues.apache.org/jira/browse/CASSANDRA-4857 > > > > We’ve seen this a few times, we’re we drop a key space and re-create it > and get inconstancy issues. > > It even happened to me mid Message thread on these boards. > > > > http://www.mail-archive.com/user%40cassandra.apache.org/msg42139.html > > > > > > > > *From:* Sebastian Estevez [mailto:sebastian.este...@datastax.com] > *Sent:* 22 May 2015 14:46 > > *To:* user@cassandra.apache.org > *Subject:* Re: Drop/Create table with same CF Name > > > > I’m aware of issues where recreating key spaces can cause inconsistency > in 2.0.13 if memTables are not flushed beforehand , is this the issues that > is resolved? > > > > Yep, that's https://issues.apache.org/jira/browse/CASSANDRA-7511 > > >All the best, > > > > *[image: datastax_logo.png] <http://www.datastax.com/>* > > Sebastián Estévez > > Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com > > [image: linkedin.png] <https://www.linkedin.com/company/datastax>[image: > facebook.png] <https://www.facebook.com/datastax>[image: twitter.png] > <https://twitter.com/datastax>[image: g+.png] > <https://plus.google.com/+Datastax/about> > <http://feeds.feedburner.com/datastax> > > > <http://cassandrasummit-datastax.com/> > > > > DataStax is the fastest, most scalable distributed database technology, > delivering Apache Cassandra to the world’s most innovative enterprises. > Datastax is built to be agile, always-on, and predictably scalable to any > size. With more than 500 customers in 45 countries, DataStax is the > database technology and transactional backbone of choice for the worlds > most innovative companies such as Netflix, Adobe, Intuit, and eBay. > > > > On Fri, May 22, 2015 at 7:53 AM, Walsh, Stephen > wrote: > > Can someone share the content on this link please, I’m aware of issues > where recreating key spaces can cause inconsistency in 2.0.13 if memTables > are not flushed beforehand , is this the issues that is resolved? > > > > > > *From:* Ken Hancock [mailto:ken.hanc...@schange.com] > *Sent:* 21 May 2015 17:13 > *To:* user@cassandra.apache.org > *Subject:* Re: Drop/Create table with same CF Name > > > > Thanks Mark (though that article doesn't appear publicly accessible for > others). > > Truncate would have been the tool of choice, however my understanding is > truncate fails unless all nodes are up and running which makes it a > non-workable choice since we can't determine when failures will occur. > > Ken > > > > On Thu, May 21, 2015 at 11:00 AM, Mark Reddy > wrote: > > Yes, it's a known issue. For more information on the topic see this > support post from DataStax: > > > > > https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 > > > Mark > > > > On 21 May 2015 at 15:31, Ken Hancock wrote: > > > > We've been running into the reused key cache issue (CASSANDRA-5202) with > dropping and recreating the same table in Cassandra 1.2.18 so we've been > testing with key caches disabled which does not seem to solve the issue. > In the latest logs it seems that old SSTables metadata gets read after the > tables have been deleted by the previous drop, eventually causing an > exception and the Thrift interface shut down. > > At this point is it a known issue that one CANNOT reuse a table name prior > to Cassandra 2.1 ? > > > > > > > > This email (including any attachments) is proprietary to Aspect Software, > Inc. and may contain information that is confidential. If you have received > this message in error, please do not read, copy or forward this message. > Please notify the sender immediately, delete it from your system and > destroy any copies. You may not further disclose or distribute this email > or its attachments. > > > This email (including any attachments) is proprietary to Aspect > Software, Inc. and may contain information that is confidential. If you > have received this message in error, please do not read, copy or forward > this message. Please notify the sender immediately, delete it from your > system and destroy any copies. You may not further disclose or distribute > this email or its attachments. >
RE: Drop/Create table with same CF Name
Thanks for the link, I don’t think your link is what I hand mind – considering it mentioned to be fixed in 2.0.13 I was referring to this “won’t fix” issue https://issues.apache.org/jira/browse/CASSANDRA-4857 We’ve seen this a few times, we’re we drop a key space and re-create it and get inconstancy issues. It even happened to me mid Message thread on these boards. http://www.mail-archive.com/user%40cassandra.apache.org/msg42139.html From: Sebastian Estevez [mailto:sebastian.este...@datastax.com] Sent: 22 May 2015 14:46 To: user@cassandra.apache.org Subject: Re: Drop/Create table with same CF Name I’m aware of issues where recreating key spaces can cause inconsistency in 2.0.13 if memTables are not flushed beforehand , is this the issues that is resolved? Yep, that's https://issues.apache.org/jira/browse/CASSANDRA-7511 All the best, [datastax_logo.png]<http://www.datastax.com/> Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com<mailto:sebastian.este...@datastax.com> [linkedin.png]<https://www.linkedin.com/company/datastax>[facebook.png]<https://www.facebook.com/datastax>[twitter.png]<https://twitter.com/datastax>[g+.png]<https://plus.google.com/+Datastax/about>[https://lh6.googleusercontent.com/24_538J0j5M0NHQx-jkRiV_IHrhsh-98hpi--Qz9b0-I4llvWuYI6LgiVJsul0AhxL0gMTOHgw3G0SvIXaT2C7fsKKa_DdQ2uOJ-bQ6h_mQ7k7iMybcR1dr1VhWgLMxcmg]<http://feeds.feedburner.com/datastax> [http://datastax.com/all/images/cs_logo_color_sm.png]<http://cassandrasummit-datastax.com/> DataStax is the fastest, most scalable distributed database technology, delivering Apache Cassandra to the world’s most innovative enterprises. Datastax is built to be agile, always-on, and predictably scalable to any size. With more than 500 customers in 45 countries, DataStax is the database technology and transactional backbone of choice for the worlds most innovative companies such as Netflix, Adobe, Intuit, and eBay. On Fri, May 22, 2015 at 7:53 AM, Walsh, Stephen mailto:stephen.wa...@aspect.com>> wrote: Can someone share the content on this link please, I’m aware of issues where recreating key spaces can cause inconsistency in 2.0.13 if memTables are not flushed beforehand , is this the issues that is resolved? From: Ken Hancock [mailto:ken.hanc...@schange.com<mailto:ken.hanc...@schange.com>] Sent: 21 May 2015 17:13 To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> Subject: Re: Drop/Create table with same CF Name Thanks Mark (though that article doesn't appear publicly accessible for others). Truncate would have been the tool of choice, however my understanding is truncate fails unless all nodes are up and running which makes it a non-workable choice since we can't determine when failures will occur. Ken On Thu, May 21, 2015 at 11:00 AM, Mark Reddy mailto:mark.l.re...@gmail.com>> wrote: Yes, it's a known issue. For more information on the topic see this support post from DataStax: https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 Mark On 21 May 2015 at 15:31, Ken Hancock mailto:ken.hanc...@schange.com>> wrote: We've been running into the reused key cache issue (CASSANDRA-5202) with dropping and recreating the same table in Cassandra 1.2.18 so we've been testing with key caches disabled which does not seem to solve the issue. In the latest logs it seems that old SSTables metadata gets read after the tables have been deleted by the previous drop, eventually causing an exception and the Thrift interface shut down. At this point is it a known issue that one CANNOT reuse a table name prior to Cassandra 2.1 ? This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments. This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.
Re: Drop/Create table with same CF Name
> > I’m aware of issues where recreating key spaces can cause inconsistency > in 2.0.13 if memTables are not flushed beforehand , is this the issues that > is resolved? Yep, that's https://issues.apache.org/jira/browse/CASSANDRA-7511 All the best, [image: datastax_logo.png] <http://www.datastax.com/> Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com [image: linkedin.png] <https://www.linkedin.com/company/datastax> [image: facebook.png] <https://www.facebook.com/datastax> [image: twitter.png] <https://twitter.com/datastax> [image: g+.png] <https://plus.google.com/+Datastax/about> <http://feeds.feedburner.com/datastax> <http://cassandrasummit-datastax.com/> DataStax is the fastest, most scalable distributed database technology, delivering Apache Cassandra to the world’s most innovative enterprises. Datastax is built to be agile, always-on, and predictably scalable to any size. With more than 500 customers in 45 countries, DataStax is the database technology and transactional backbone of choice for the worlds most innovative companies such as Netflix, Adobe, Intuit, and eBay. On Fri, May 22, 2015 at 7:53 AM, Walsh, Stephen wrote: > Can someone share the content on this link please, I’m aware of issues > where recreating key spaces can cause inconsistency in 2.0.13 if memTables > are not flushed beforehand , is this the issues that is resolved? > > > > > > *From:* Ken Hancock [mailto:ken.hanc...@schange.com] > *Sent:* 21 May 2015 17:13 > *To:* user@cassandra.apache.org > *Subject:* Re: Drop/Create table with same CF Name > > > > Thanks Mark (though that article doesn't appear publicly accessible for > others). > > Truncate would have been the tool of choice, however my understanding is > truncate fails unless all nodes are up and running which makes it a > non-workable choice since we can't determine when failures will occur. > > Ken > > > > On Thu, May 21, 2015 at 11:00 AM, Mark Reddy > wrote: > > Yes, it's a known issue. For more information on the topic see this > support post from DataStax: > > > > > https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 > > > Mark > > > > On 21 May 2015 at 15:31, Ken Hancock wrote: > > > > We've been running into the reused key cache issue (CASSANDRA-5202) with > dropping and recreating the same table in Cassandra 1.2.18 so we've been > testing with key caches disabled which does not seem to solve the issue. > In the latest logs it seems that old SSTables metadata gets read after the > tables have been deleted by the previous drop, eventually causing an > exception and the Thrift interface shut down. > > At this point is it a known issue that one CANNOT reuse a table name prior > to Cassandra 2.1 ? > > > > > > > This email (including any attachments) is proprietary to Aspect > Software, Inc. and may contain information that is confidential. If you > have received this message in error, please do not read, copy or forward > this message. Please notify the sender immediately, delete it from your > system and destroy any copies. You may not further disclose or distribute > this email or its attachments. >
Re: Drop/Create table with same CF Name
I hadn't run into that one, but I did run into the old (deleted) SSTables somehow getting injected back into the dropped column family, resulting in a exception and the Thrift connection closing down. On Fri, May 22, 2015 at 7:53 AM, Walsh, Stephen wrote: > Can someone share the content on this link please, I’m aware of issues > where recreating key spaces can cause inconsistency in 2.0.13 if memTables > are not flushed beforehand , is this the issues that is resolved? > > > > > > *From:* Ken Hancock [mailto:ken.hanc...@schange.com] > *Sent:* 21 May 2015 17:13 > *To:* user@cassandra.apache.org > *Subject:* Re: Drop/Create table with same CF Name > > > > Thanks Mark (though that article doesn't appear publicly accessible for > others). > > Truncate would have been the tool of choice, however my understanding is > truncate fails unless all nodes are up and running which makes it a > non-workable choice since we can't determine when failures will occur. > > Ken > > > > On Thu, May 21, 2015 at 11:00 AM, Mark Reddy > wrote: > > Yes, it's a known issue. For more information on the topic see this > support post from DataStax: > > > > > https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 > > > Mark > > > > On 21 May 2015 at 15:31, Ken Hancock wrote: > > > > We've been running into the reused key cache issue (CASSANDRA-5202) with > dropping and recreating the same table in Cassandra 1.2.18 so we've been > testing with key caches disabled which does not seem to solve the issue. > In the latest logs it seems that old SSTables metadata gets read after the > tables have been deleted by the previous drop, eventually causing an > exception and the Thrift interface shut down. > > At this point is it a known issue that one CANNOT reuse a table name prior > to Cassandra 2.1 ? > > > > > > > This email (including any attachments) is proprietary to Aspect > Software, Inc. and may contain information that is confidential. If you > have received this message in error, please do not read, copy or forward > this message. Please notify the sender immediately, delete it from your > system and destroy any copies. You may not further disclose or distribute > this email or its attachments. >
RE: Drop/Create table with same CF Name
Can someone share the content on this link please, I’m aware of issues where recreating key spaces can cause inconsistency in 2.0.13 if memTables are not flushed beforehand , is this the issues that is resolved? From: Ken Hancock [mailto:ken.hanc...@schange.com] Sent: 21 May 2015 17:13 To: user@cassandra.apache.org Subject: Re: Drop/Create table with same CF Name Thanks Mark (though that article doesn't appear publicly accessible for others). Truncate would have been the tool of choice, however my understanding is truncate fails unless all nodes are up and running which makes it a non-workable choice since we can't determine when failures will occur. Ken On Thu, May 21, 2015 at 11:00 AM, Mark Reddy mailto:mark.l.re...@gmail.com>> wrote: Yes, it's a known issue. For more information on the topic see this support post from DataStax: https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 Mark On 21 May 2015 at 15:31, Ken Hancock mailto:ken.hanc...@schange.com>> wrote: We've been running into the reused key cache issue (CASSANDRA-5202) with dropping and recreating the same table in Cassandra 1.2.18 so we've been testing with key caches disabled which does not seem to solve the issue. In the latest logs it seems that old SSTables metadata gets read after the tables have been deleted by the previous drop, eventually causing an exception and the Thrift interface shut down. At this point is it a known issue that one CANNOT reuse a table name prior to Cassandra 2.1 ? This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.
Re: Drop/Create table with same CF Name
Thanks Mark (though that article doesn't appear publicly accessible for others). Truncate would have been the tool of choice, however my understanding is truncate fails unless all nodes are up and running which makes it a non-workable choice since we can't determine when failures will occur. Ken On Thu, May 21, 2015 at 11:00 AM, Mark Reddy wrote: > Yes, it's a known issue. For more information on the topic see this > support post from DataStax: > > > https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 > > Mark > > On 21 May 2015 at 15:31, Ken Hancock wrote: > >> >> We've been running into the reused key cache issue (CASSANDRA-5202) with >> dropping and recreating the same table in Cassandra 1.2.18 so we've been >> testing with key caches disabled which does not seem to solve the issue. >> In the latest logs it seems that old SSTables metadata gets read after the >> tables have been deleted by the previous drop, eventually causing an >> exception and the Thrift interface shut down. >> >> At this point is it a known issue that one CANNOT reuse a table name >> prior to Cassandra 2.1 ? >> > >
Re: Drop/Create table with same CF Name
Yes, it's a known issue. For more information on the topic see this support post from DataStax: https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 Mark On 21 May 2015 at 15:31, Ken Hancock wrote: > > We've been running into the reused key cache issue (CASSANDRA-5202) with > dropping and recreating the same table in Cassandra 1.2.18 so we've been > testing with key caches disabled which does not seem to solve the issue. > In the latest logs it seems that old SSTables metadata gets read after the > tables have been deleted by the previous drop, eventually causing an > exception and the Thrift interface shut down. > > At this point is it a known issue that one CANNOT reuse a table name prior > to Cassandra 2.1 ? >
