MATERIALIZED VIEW difference in 3.0.3 to 3.0.7/3.7

There is behavioural difference between 3.0.3 and (3.0.7/3.7) for below schema in materialized view. CREATE TABLE ks.pa ( > id bigint, > sub_id text, > name text, > class text, > r_id bigint, > k_id bigint, > created timestamp, > priority int, > updated

C* 2.2.7 ?

Hi, are there any plans to release 2.2.7 any time soon? kind regards, Christian

Re: MATERIALIZED VIEW difference in 3.0.3 to 3.0.7/3.7

This appears to be a bug introduced in some refactoring of the materialized view code. I logged CASSANDRA-12044 for this. https://issues.apache.org/jira/browse/CASSANDRA-12044 -- Michael Mior michael.m...@gmail.com 2016-06-21 7:32 GMT-04:00 Atul Saroha : > There is

Re: Incremental repairs in 3.0

Thanks for answer! >It may still be a good idea to manually migrate if you have a sizable amount >of dataNo, it would be brand new ;-) 3.0 cluster On Tuesday, June 21, 2016 1:21 AM, Bryan Cheng wrote: Sorry, meant to say "therefore manual migration procedure

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

I have experienced similar duplicate primary keys behavior with couple of tables after upgrading from 2.2.x to 3.0.x. See comments on the Jira issue I opened at the time over there: https://issues.apache.org/jira/browse/CASSANDRA-11887 On Tue, Jun 21, 2016 at 10:47 AM, Oskar Kjellin

Cluster not working after upgrade from 2.1.12 to 3.5.0

Hi, We've done this upgrade in both dev and stage before and we did not see similar issues. After upgrading production today we have a lot issues tho. The main issue is that the Datastax client quite often does not get the data (even though it's the same query). I see similar flakyness by simply

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

Hmm, no way we can do that in prod :/ Sent from my iPhone > On 21 juni 2016, at 18:50, Julien Anguenot wrote: > > See my comments on the issue: I had to truncate and reinsert data in > these corrupted tables. > > AFAIK, there is no evidence that UDTs are responsible of

Re: MATERIALIZED VIEW difference in 3.0.3 to 3.0.7/3.7

It turns out this behaviour was not intended to be allowed and constructing MVs like this can lead to issues. See https://issues.apache.org/jira/browse/CASSANDRA-9928 -- Michael Mior michael.m...@gmail.com 2016-06-21 7:32 GMT-04:00 Atul Saroha : > There is behavioural

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

Yea I saw that one. We're not using UDT in the affected tables tho. Did you resolve it? Sent from my iPhone > On 21 juni 2016, at 18:27, Julien Anguenot wrote: > > I have experienced similar duplicate primary keys behavior with couple > of tables after upgrading from

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

See my comments on the issue: I had to truncate and reinsert data in these corrupted tables. AFAIK, there is no evidence that UDTs are responsible of this bad behavior. On Tue, Jun 21, 2016 at 11:45 AM, Oskar Kjellin wrote: > Yea I saw that one. We're not using UDT in

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

Did you see similar issues when querying using a driver? Because we get no results in the driver what so ever Sent from my iPhone > On 21 juni 2016, at 18:50, Julien Anguenot wrote: > > See my comments on the issue: I had to truncate and reinsert data in > these

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

Hi Oskar, I know this won't help you as quickly as you would like but please consider updating the JIRA issue with details of your environment as it may help move the investigation along. Good luck! On Tue, Jun 21, 2016 at 12:21 PM, Julien Anguenot wrote: > You could try

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

AFAICT, the issue does not seem to be driver related as the duplicates where showing up both using the cqlsh and Java driver. In addition, the sstabledump output contained the actual duplicates. (see Jira issue) On Tue, Jun 21, 2016 at 12:04 PM, Oskar Kjellin wrote: >

Re: Cluster not working after upgrade from 2.1.12 to 3.5.0

You could try to sstabledump that one corrupted table, write some (Python) code to get rid of the duplicates processing that stabledump output (might not be bullet proof depending on data, I agree), truncate and re-insert them back in that table without duplicates. On Tue, Jun 21, 2016 at 11:52