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 times
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 behavioural difference betw
Hi,
are there any plans to release 2.2.7 any time soon?
kind regards,
Christian
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 should be
UNnecessary"
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
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 wrote:
> Hi
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 2.2.x to 3.0.x.
>
> See
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 the affected tables tho.
>
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 this bad behavior.
>
>>
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 corrupted tables.
>
> AFAIK,
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 difference between 3.0.3
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:
> Did you see similar issues w
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 AM
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 to sstabledump that on
14 matches
Mail list logo
