Re: Lightweight transaction inside a batch : request rejected

[Ben Slater]

Yep, you would have to select the whole map and then pull out the
particular value you want in your application. I didn’t actually realise
you couldn’t just specify a particular map element in a select like you can
in an update but it appears there is a long running Jira for this:
https://issues.apache.org/jira/browse/CASSANDRA-7396

Cheers
Ben

On Tue, 25 Oct 2016 at 16:25 Mickael Delanoë  wrote:

> I can't do this, otherwhise i won't be able to query the item_id using a
> key with a query like :
> Select * from item_id_by_key where user_id=... and key=
>
> Le 25 oct. 2016 07:15, "Ben Slater"  a écrit :
>
> Move item_id_by_key into a collection field in item table? (Would
> probably be a “better” C* data model anyway.)
>
> On Tue, 25 Oct 2016 at 16:08 Mickael Delanoë  wrote:
>
> Ok, I understand, thanks.
> So now i would like to know if there is some best practices to do what i
> want.
> I.e inserting entries in several tables (with same partition key) only if
> there is not already an entry in the main table.
>
> Keep in mind i wanted to do that inside a single batch because I can have
> 2 concurrent request trying to insert something different but with the same
> primary key in the main table.
>
> If i split the batch in 2 requests(1 with the LWT, 1 with the rest), how
> can i ensure the last batch won't override the previous data and that the
> whole data will be saved (in case of a problem between request1 and
> request2) ?
>
> Le 24 oct. 2016 12:47, "DuyHai Doan"  a écrit :
>
>
>
> "So I guess in that case the Paxos operation does not span multiple table
> but operates only the table that has the condition. Am I wrong?"
>
> --> The fact that you're using a BATCH with LWT means that either ALL
> statements succeed or NONE. And to guarantee this, Paxos ballot must cover
> all statements. In your case since they span on multiple tables it's not
> possible
>
> On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delanoë 
> wrote:
>
> Thanks DuyHai for the info.
> I already see this JIRA, however the use case I describe is slightly
> different from the JIRA as there is only ONE condition on ONE table. Other
> statements of the batch does not have any condition.
> So I guess in that case the Paxos operation does not span multiple table
> but operates only the table that has the condition. Am I wrong?
>
>
>
> 2016-10-24 10:21 GMT+02:00 DuyHai Doan :
>
> As far as I remember, there is an optimization in Cassandra to manage
> Paxos ballot per table. So asking a Paxos operation to span multiple tables
> (even if same partition key) would require a lot of changes in the current
> impl.
>
> The question has already been raised, you may want to convince the
> committers by adding some comments here:
> https://issues.apache.org/jira/browse/CASSANDRA-10085
>
> On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë 
> wrote:
>
> Hi,
>
> I would like to use lightweight transaction inside a batch but the request
> is rejected by cassandra, however I think this is a use case than could be
> handled without problem.
> Below is what I wanted to do.
>
> I am using cassandra 3.7.
>
> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
>
> CREATE TABLE test_ksp.item (
> user_id bigint,
> item_id text,
> item_value text,
> item_key1 text,
> item_key2 text,
> PRIMARY KEY ((user_id), item_id));
>
> CREATE TABLE test_ksp.item_id_by_key (
> user_id bigint,
> item_key text,
> item_id text,
> PRIMARY KEY ((user_id), item_key));
>
> USE test_ksp;
>
> BEGIN BATCH
> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
> 'key-XYZ-123', 'i11');
> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
> 'key-ABC-789', 'i11');
> APPLY BATCH;
>
>
> So as you can see this is a batch that targets 2 tables but with the same
> partition key (i.e the same target nodes). Moreover It uses only ONE
> condition on one table only.
> I don't understand why cassandra returns an error "Batch with conditions
> cannot span multiple tables" in that case.
>
> I understand that if I had used several conditions on different tables it
> could be a problem, but in my case there is only one condition and moreover
> I have always the same partition key for every table inside the batch.
> As there is only one condition, I expected the paxos protocol just act on
> this condition and as the partition keys are all the same, the paxos
> protocol has only to work with the same replica nodes (not span across
> multiple partition).
> In my point of view this is as if the LWT was in a single statement,
> except that after the LWT is accepted a complete batch has to be 

Re: Lightweight transaction inside a batch : request rejected

[Mickael Delanoë]

I can't do this, otherwhise i won't be able to query the item_id using a
key with a query like :
Select * from item_id_by_key where user_id=... and key=

Le 25 oct. 2016 07:15, "Ben Slater"  a écrit :

> Move item_id_by_key into a collection field in item table? (Would
> probably be a “better” C* data model anyway.)
>
> On Tue, 25 Oct 2016 at 16:08 Mickael Delanoë  wrote:
>
>> Ok, I understand, thanks.
>> So now i would like to know if there is some best practices to do what i
>> want.
>> I.e inserting entries in several tables (with same partition key) only if
>> there is not already an entry in the main table.
>>
>> Keep in mind i wanted to do that inside a single batch because I can have
>> 2 concurrent request trying to insert something different but with the same
>> primary key in the main table.
>>
>> If i split the batch in 2 requests(1 with the LWT, 1 with the rest), how
>> can i ensure the last batch won't override the previous data and that the
>> whole data will be saved (in case of a problem between request1 and
>> request2) ?
>>
>> Le 24 oct. 2016 12:47, "DuyHai Doan"  a écrit :
>>
>>
>>
>> "So I guess in that case the Paxos operation does not span multiple table
>> but operates only the table that has the condition. Am I wrong?"
>>
>> --> The fact that you're using a BATCH with LWT means that either ALL
>> statements succeed or NONE. And to guarantee this, Paxos ballot must cover
>> all statements. In your case since they span on multiple tables it's not
>> possible
>>
>> On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delanoë 
>> wrote:
>>
>> Thanks DuyHai for the info.
>> I already see this JIRA, however the use case I describe is slightly
>> different from the JIRA as there is only ONE condition on ONE table. Other
>> statements of the batch does not have any condition.
>> So I guess in that case the Paxos operation does not span multiple table
>> but operates only the table that has the condition. Am I wrong?
>>
>>
>>
>> 2016-10-24 10:21 GMT+02:00 DuyHai Doan :
>>
>> As far as I remember, there is an optimization in Cassandra to manage
>> Paxos ballot per table. So asking a Paxos operation to span multiple tables
>> (even if same partition key) would require a lot of changes in the current
>> impl.
>>
>> The question has already been raised, you may want to convince the
>> committers by adding some comments here: https://issues.apache.
>> org/jira/browse/CASSANDRA-10085
>>
>> On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë 
>> wrote:
>>
>> Hi,
>>
>> I would like to use lightweight transaction inside a batch but the
>> request is rejected by cassandra, however I think this is a use case than
>> could be handled without problem.
>> Below is what I wanted to do.
>>
>> I am using cassandra 3.7.
>>
>> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
>> 'replication_factor': '1'};
>>
>> CREATE TABLE test_ksp.item (
>> user_id bigint,
>> item_id text,
>> item_value text,
>> item_key1 text,
>> item_key2 text,
>> PRIMARY KEY ((user_id), item_id));
>>
>> CREATE TABLE test_ksp.item_id_by_key (
>> user_id bigint,
>> item_key text,
>> item_id text,
>> PRIMARY KEY ((user_id), item_key));
>>
>> USE test_ksp;
>>
>> BEGIN BATCH
>> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
>> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>> 'key-XYZ-123', 'i11');
>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>> 'key-ABC-789', 'i11');
>> APPLY BATCH;
>>
>>
>> So as you can see this is a batch that targets 2 tables but with the same
>> partition key (i.e the same target nodes). Moreover It uses only ONE
>> condition on one table only.
>> I don't understand why cassandra returns an error "Batch with conditions
>> cannot span multiple tables" in that case.
>>
>> I understand that if I had used several conditions on different tables it
>> could be a problem, but in my case there is only one condition and moreover
>> I have always the same partition key for every table inside the batch.
>> As there is only one condition, I expected the paxos protocol just act on
>> this condition and as the partition keys are all the same, the paxos
>> protocol has only to work with the same replica nodes (not span across
>> multiple partition).
>> In my point of view this is as if the LWT was in a single statement,
>> except that after the LWT is accepted a complete batch has to be executed.
>>
>> Is there someone that could explain why this use case need to be rejected
>> by cassandra? And do you think this is something that cassandra could
>> handle in a future version ?
>>
>> Regards,
>> Mickaël
>>
>>
>>
>>
>>
>> --
>> Mickaël Delanoë
>>
>>
>>
>>

Re: Lightweight transaction inside a batch : request rejected

[Ben Slater]

Move item_id_by_key into a collection field in item table? (Would probably
be a “better” C* data model anyway.)

On Tue, 25 Oct 2016 at 16:08 Mickael Delanoë  wrote:

> Ok, I understand, thanks.
> So now i would like to know if there is some best practices to do what i
> want.
> I.e inserting entries in several tables (with same partition key) only if
> there is not already an entry in the main table.
>
> Keep in mind i wanted to do that inside a single batch because I can have
> 2 concurrent request trying to insert something different but with the same
> primary key in the main table.
>
> If i split the batch in 2 requests(1 with the LWT, 1 with the rest), how
> can i ensure the last batch won't override the previous data and that the
> whole data will be saved (in case of a problem between request1 and
> request2) ?
>
> Le 24 oct. 2016 12:47, "DuyHai Doan"  a écrit :
>
>
>
> "So I guess in that case the Paxos operation does not span multiple table
> but operates only the table that has the condition. Am I wrong?"
>
> --> The fact that you're using a BATCH with LWT means that either ALL
> statements succeed or NONE. And to guarantee this, Paxos ballot must cover
> all statements. In your case since they span on multiple tables it's not
> possible
>
> On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delanoë 
> wrote:
>
> Thanks DuyHai for the info.
> I already see this JIRA, however the use case I describe is slightly
> different from the JIRA as there is only ONE condition on ONE table. Other
> statements of the batch does not have any condition.
> So I guess in that case the Paxos operation does not span multiple table
> but operates only the table that has the condition. Am I wrong?
>
>
>
> 2016-10-24 10:21 GMT+02:00 DuyHai Doan :
>
> As far as I remember, there is an optimization in Cassandra to manage
> Paxos ballot per table. So asking a Paxos operation to span multiple tables
> (even if same partition key) would require a lot of changes in the current
> impl.
>
> The question has already been raised, you may want to convince the
> committers by adding some comments here:
> https://issues.apache.org/jira/browse/CASSANDRA-10085
>
> On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë 
> wrote:
>
> Hi,
>
> I would like to use lightweight transaction inside a batch but the request
> is rejected by cassandra, however I think this is a use case than could be
> handled without problem.
> Below is what I wanted to do.
>
> I am using cassandra 3.7.
>
> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
>
> CREATE TABLE test_ksp.item (
> user_id bigint,
> item_id text,
> item_value text,
> item_key1 text,
> item_key2 text,
> PRIMARY KEY ((user_id), item_id));
>
> CREATE TABLE test_ksp.item_id_by_key (
> user_id bigint,
> item_key text,
> item_id text,
> PRIMARY KEY ((user_id), item_key));
>
> USE test_ksp;
>
> BEGIN BATCH
> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
> 'key-XYZ-123', 'i11');
> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
> 'key-ABC-789', 'i11');
> APPLY BATCH;
>
>
> So as you can see this is a batch that targets 2 tables but with the same
> partition key (i.e the same target nodes). Moreover It uses only ONE
> condition on one table only.
> I don't understand why cassandra returns an error "Batch with conditions
> cannot span multiple tables" in that case.
>
> I understand that if I had used several conditions on different tables it
> could be a problem, but in my case there is only one condition and moreover
> I have always the same partition key for every table inside the batch.
> As there is only one condition, I expected the paxos protocol just act on
> this condition and as the partition keys are all the same, the paxos
> protocol has only to work with the same replica nodes (not span across
> multiple partition).
> In my point of view this is as if the LWT was in a single statement,
> except that after the LWT is accepted a complete batch has to be executed.
>
> Is there someone that could explain why this use case need to be rejected
> by cassandra? And do you think this is something that cassandra could
> handle in a future version ?
>
> Regards,
> Mickaël
>
>
>
>
>
> --
> Mickaël Delanoë
>
>
>
>

Re: Lightweight transaction inside a batch : request rejected

[Mickael Delanoë]

Ok, I understand, thanks.
So now i would like to know if there is some best practices to do what i
want.
I.e inserting entries in several tables (with same partition key) only if
there is not already an entry in the main table.

Keep in mind i wanted to do that inside a single batch because I can have 2
concurrent request trying to insert something different but with the same
primary key in the main table.

If i split the batch in 2 requests(1 with the LWT, 1 with the rest), how
can i ensure the last batch won't override the previous data and that the
whole data will be saved (in case of a problem between request1 and
request2) ?

Le 24 oct. 2016 12:47, "DuyHai Doan"  a écrit :



"So I guess in that case the Paxos operation does not span multiple table
but operates only the table that has the condition. Am I wrong?"

--> The fact that you're using a BATCH with LWT means that either ALL
statements succeed or NONE. And to guarantee this, Paxos ballot must cover
all statements. In your case since they span on multiple tables it's not
possible

On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delanoë 
wrote:

> Thanks DuyHai for the info.
> I already see this JIRA, however the use case I describe is slightly
> different from the JIRA as there is only ONE condition on ONE table. Other
> statements of the batch does not have any condition.
> So I guess in that case the Paxos operation does not span multiple table
> but operates only the table that has the condition. Am I wrong?
>
>
>
> 2016-10-24 10:21 GMT+02:00 DuyHai Doan :
>
>> As far as I remember, there is an optimization in Cassandra to manage
>> Paxos ballot per table. So asking a Paxos operation to span multiple tables
>> (even if same partition key) would require a lot of changes in the current
>> impl.
>>
>> The question has already been raised, you may want to convince the
>> committers by adding some comments here: https://issues.apache.or
>> g/jira/browse/CASSANDRA-10085
>>
>> On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë 
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to use lightweight transaction inside a batch but the
>>> request is rejected by cassandra, however I think this is a use case than
>>> could be handled without problem.
>>> Below is what I wanted to do.
>>>
>>> I am using cassandra 3.7.
>>>
>>> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
>>> 'replication_factor': '1'};
>>>
>>> CREATE TABLE test_ksp.item (
>>> user_id bigint,
>>> item_id text,
>>> item_value text,
>>> item_key1 text,
>>> item_key2 text,
>>> PRIMARY KEY ((user_id), item_id));
>>>
>>> CREATE TABLE test_ksp.item_id_by_key (
>>> user_id bigint,
>>> item_key text,
>>> item_id text,
>>> PRIMARY KEY ((user_id), item_key));
>>>
>>> USE test_ksp;
>>>
>>> BEGIN BATCH
>>> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
>>> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
>>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>>> 'key-XYZ-123', 'i11');
>>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>>> 'key-ABC-789', 'i11');
>>> APPLY BATCH;
>>>
>>>
>>> So as you can see this is a batch that targets 2 tables but with the
>>> same partition key (i.e the same target nodes). Moreover It uses only ONE
>>> condition on one table only.
>>> I don't understand why cassandra returns an error "Batch with conditions
>>> cannot span multiple tables" in that case.
>>>
>>> I understand that if I had used several conditions on different tables
>>> it could be a problem, but in my case there is only one condition and
>>> moreover I have always the same partition key for every table inside the
>>> batch.
>>> As there is only one condition, I expected the paxos protocol just act
>>> on this condition and as the partition keys are all the same, the paxos
>>> protocol has only to work with the same replica nodes (not span across
>>> multiple partition).
>>> In my point of view this is as if the LWT was in a single statement,
>>> except that after the LWT is accepted a complete batch has to be executed.
>>>
>>> Is there someone that could explain why this use case need to be
>>> rejected by cassandra? And do you think this is something that cassandra
>>> could handle in a future version ?
>>>
>>> Regards,
>>> Mickaël
>>>
>>>
>>
>
>
> --
> Mickaël Delanoë
>

Re: Cluster Maintenance Mishap

[kurt Greaves]

On 21 October 2016 at 15:15, Branton Davis 
wrote:

> For example, I forgot to mention until I read your comment, that the
> instances showed as UN (up, normal) instead of UJ (up, joining) while they
> were apparently bootstrapping.


It's likely these nodes were configured as seed nodes, which means they
wouldn't have bootstrapped. In this case it shouldn't have been an issue
after you fixed up the data directories.

Kurt Greaves
k...@instaclustr.com
www.instaclustr.com

Re: Doing an upsert into a collection?

[kurt Greaves]

On 24 October 2016 at 22:16, Ali Akhtar  wrote:

> *UPDATE movie set ratings.rating = 5 WHERE ratings.user = 'bob'*


You won't be able to do this because you're trying to update a row without
specifying the primary key. Also, even if you did add the PK to the where,
you've specified a list of (frozen) ratings, so ratings.rating and
ratings.user doesn't make sense.

Collection types can't be part of the primary key, so updating as you've
mentioned above won't really be possible.

Kurt Greaves
k...@instaclustr.com
www.instaclustr.com

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Stefania Alborghetti]

I'm sure you can share the schema and data privately with the ticket
assignee, when the ticket gets assigned and looked at.

If it was a schema change problem, you can try going back to the old schema
if you can recall what it was, but I cannot guarantee this would work
without knowing the root cause. Same thing regarding which release to try,
without knowing the root cause, it's really not possible to advise a
specific release.

The easiest thing to do is to skip the mutations with problems. You still
loose some data but at least not all data. If you see this in your logs:

Replay stopped. If you wish to override this error and continue starting
the node ignoring commit log replay problems, specify
-Dcassandra.commitlog.ignorereplayerrors=true on the command line.

Then it means that you can start Cassandra with
-Dcassandra.commitlog.ignorereplayerrors=true
and it will carry on even if it cannot parse some mutations, which will be
saved in the /tmp folder.

If it was a schema change problem, then you shouldn't need to start with
this property more than once. If the problem persists with new commit log
segments, then it's definitely another problem and you should really open a
ticket.

On Tue, Oct 25, 2016 at 10:36 AM, kurt Greaves  wrote:

>
> On 25 October 2016 at 01:34, Ali Akhtar  wrote:
>
>> I want some of the newer UDT features, like not needing to have frozen
>> UDTs
>
>
> You can try Instaclustr's 3.7 LTS release which is just 3.7 with some
> backported fixes from later versions. If you absolutely need those new
> features it's probably your best bet (until 4.0), however note that it's
> still 3.7 and likely less stable than the latest 3.0.x releases.
>
> https://github.com/instaclustr/cassandra
>
> Read the README at the repo for more info.
>
> Kurt Greaves
> k...@instaclustr.com
> www.instaclustr.com
>



-- 


Stefania Alborghetti

|+852 6114 9265| stefania.alborghe...@datastax.com

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[kurt Greaves]

On 25 October 2016 at 01:34, Ali Akhtar  wrote:

> I want some of the newer UDT features, like not needing to have frozen UDTs


You can try Instaclustr's 3.7 LTS release which is just 3.7 with some
backported fixes from later versions. If you absolutely need those new
features it's probably your best bet (until 4.0), however note that it's
still 3.7 and likely less stable than the latest 3.0.x releases.

https://github.com/instaclustr/cassandra

Read the README at the repo for more info.

Kurt Greaves
k...@instaclustr.com
www.instaclustr.com

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Jonathan Haddad]

Nobody that I'm aware of can verify tick tock releases as stable.  You can
use the latest stuff if you want, just know there's probably bugs (like
you're seeing) that nobody is aware of.  Tick Tock releases (3.1, 3.2, etc)
should really be thought of as development releases.  They won't receive
bug fixes even under circumstances like you've seen in 3.9.  The only way
you will be able to get a bug fix for the issue you've just found is by
backporting it yourself or upgrading to a new version with new features.

On Mon, Oct 24, 2016 at 6:35 PM Ali Akhtar  wrote:

> I want some of the newer UDT features, like not needing to have frozen UDTs
>
> On Tue, Oct 25, 2016 at 6:34 AM, Ali Akhtar  wrote:
>
> 3.0.x? Isn't 3.7 stable?
>
> On Tue, Oct 25, 2016 at 6:32 AM, Jonathan Haddad 
> wrote:
>
> If you're not in prod *yet*, I once again recommend not using 3.9 for
> anything serious.  Use the latest 3.0.x.
>
> On Mon, Oct 24, 2016 at 6:19 PM Ali Akhtar  wrote:
>
> Stefania,
>
> As this is just on my dev laptop, what I'm really looking for is a quick
> 1-2 min fix to this solution that will act as a workaround.
>
> If I drop the keyspace and recreate it, will that fix this problem? Or do
> I need to uninstall 3.9 and go back to 3.7?
>
> I probably have made a couple of changes to the schema of the tables after
> I first created them.
>
> Happy to share the schema with you privately if it will lead to a 1-2 min
> fix to this problem for me.
>
> On Tue, Oct 25, 2016 at 5:59 AM, Stefania Alborghetti <
> stefania.alborghe...@datastax.com> wrote:
>
> Did the schema change? This would be 12397.
>
> If not, and if you don't mind sharing the data, or you have the steps to
> reproduce it, could you please open a ticket so it can be looked at? You
> need to attach the schema as well.
>
> On Mon, Oct 24, 2016 at 9:33 PM, Ali Akhtar  wrote:
>
> Its 'text'.  Don't know the answer of the 2nd question.
>
> On Mon, Oct 24, 2016 at 6:31 PM, Jonathan Haddad 
> wrote:
>
> What type is board id? Is the value a tombstone?
>
> On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:
>
> Thanks, but I did come across those, it doesn't look like they provide a
> resolution.
>
> On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan  wrote:
>
> You may read those:
>
> https://issues.apache.org/jira/browse/CASSANDRA-12121
> https://issues.apache.org/jira/browse/CASSANDRA-12397
>
> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar  wrote:
>
> Any workarounds that don't involve me having to figure out how to
> uninstall and re-install a different version?
>
> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:
>
> 3.9..
>
> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan  wrote:
>
> Which version of C* ? There was similar issues with commitlogs in tic-toc
> versions.
>
> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:
>
> I have a single node cassandra installation on my dev laptop, which is
> used just for dev / testing.
>
> Recently, whenever I restart my laptop, Cassandra fails to start when I
> run it via 'sudo service cassandra start'.
>
> Doing a tail on /var/log/cassandra/system.log gives this log:
>
> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
> Exiting due to error while processing commit log during initialization.*
> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
> enough bytes to read 0th field board_id*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> 

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Ali Akhtar]

I want some of the newer UDT features, like not needing to have frozen UDTs

On Tue, Oct 25, 2016 at 6:34 AM, Ali Akhtar  wrote:

> 3.0.x? Isn't 3.7 stable?
>
> On Tue, Oct 25, 2016 at 6:32 AM, Jonathan Haddad 
> wrote:
>
>> If you're not in prod *yet*, I once again recommend not using 3.9 for
>> anything serious.  Use the latest 3.0.x.
>>
>> On Mon, Oct 24, 2016 at 6:19 PM Ali Akhtar  wrote:
>>
>>> Stefania,
>>>
>>> As this is just on my dev laptop, what I'm really looking for is a quick
>>> 1-2 min fix to this solution that will act as a workaround.
>>>
>>> If I drop the keyspace and recreate it, will that fix this problem? Or
>>> do I need to uninstall 3.9 and go back to 3.7?
>>>
>>> I probably have made a couple of changes to the schema of the tables
>>> after I first created them.
>>>
>>> Happy to share the schema with you privately if it will lead to a 1-2
>>> min fix to this problem for me.
>>>
>>> On Tue, Oct 25, 2016 at 5:59 AM, Stefania Alborghetti <
>>> stefania.alborghe...@datastax.com> wrote:
>>>
>>> Did the schema change? This would be 12397.
>>>
>>> If not, and if you don't mind sharing the data, or you have the steps to
>>> reproduce it, could you please open a ticket so it can be looked at? You
>>> need to attach the schema as well.
>>>
>>> On Mon, Oct 24, 2016 at 9:33 PM, Ali Akhtar 
>>> wrote:
>>>
>>> Its 'text'.  Don't know the answer of the 2nd question.
>>>
>>> On Mon, Oct 24, 2016 at 6:31 PM, Jonathan Haddad 
>>> wrote:
>>>
>>> What type is board id? Is the value a tombstone?
>>>
>>> On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:
>>>
>>> Thanks, but I did come across those, it doesn't look like they provide a
>>> resolution.
>>>
>>> On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan 
>>> wrote:
>>>
>>> You may read those:
>>>
>>> https://issues.apache.org/jira/browse/CASSANDRA-12121
>>> https://issues.apache.org/jira/browse/CASSANDRA-12397
>>>
>>> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar 
>>> wrote:
>>>
>>> Any workarounds that don't involve me having to figure out how to
>>> uninstall and re-install a different version?
>>>
>>> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar 
>>> wrote:
>>>
>>> 3.9..
>>>
>>> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan 
>>> wrote:
>>>
>>> Which version of C* ? There was similar issues with commitlogs in
>>> tic-toc versions.
>>>
>>> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar 
>>> wrote:
>>>
>>> I have a single node cassandra installation on my dev laptop, which is
>>> used just for dev / testing.
>>>
>>> Recently, whenever I restart my laptop, Cassandra fails to start when I
>>> run it via 'sudo service cassandra start'.
>>>
>>> Doing a tail on /var/log/cassandra/system.log gives this log:
>>>
>>> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
>>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
>>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
>>> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
>>> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
>>> Exiting due to error while processing commit log during initialization.*
>>> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>>> Unexpected error deserializing mutation; saved to
>>> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
>>> mutation against a table with the same name but incompatible schema.
>>> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
>>> enough bytes to read 0th field board_id*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> 

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Ali Akhtar]

3.0.x? Isn't 3.7 stable?

On Tue, Oct 25, 2016 at 6:32 AM, Jonathan Haddad  wrote:

> If you're not in prod *yet*, I once again recommend not using 3.9 for
> anything serious.  Use the latest 3.0.x.
>
> On Mon, Oct 24, 2016 at 6:19 PM Ali Akhtar  wrote:
>
>> Stefania,
>>
>> As this is just on my dev laptop, what I'm really looking for is a quick
>> 1-2 min fix to this solution that will act as a workaround.
>>
>> If I drop the keyspace and recreate it, will that fix this problem? Or do
>> I need to uninstall 3.9 and go back to 3.7?
>>
>> I probably have made a couple of changes to the schema of the tables
>> after I first created them.
>>
>> Happy to share the schema with you privately if it will lead to a 1-2 min
>> fix to this problem for me.
>>
>> On Tue, Oct 25, 2016 at 5:59 AM, Stefania Alborghetti <
>> stefania.alborghe...@datastax.com> wrote:
>>
>> Did the schema change? This would be 12397.
>>
>> If not, and if you don't mind sharing the data, or you have the steps to
>> reproduce it, could you please open a ticket so it can be looked at? You
>> need to attach the schema as well.
>>
>> On Mon, Oct 24, 2016 at 9:33 PM, Ali Akhtar  wrote:
>>
>> Its 'text'.  Don't know the answer of the 2nd question.
>>
>> On Mon, Oct 24, 2016 at 6:31 PM, Jonathan Haddad 
>> wrote:
>>
>> What type is board id? Is the value a tombstone?
>>
>> On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:
>>
>> Thanks, but I did come across those, it doesn't look like they provide a
>> resolution.
>>
>> On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan 
>> wrote:
>>
>> You may read those:
>>
>> https://issues.apache.org/jira/browse/CASSANDRA-12121
>> https://issues.apache.org/jira/browse/CASSANDRA-12397
>>
>> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar 
>> wrote:
>>
>> Any workarounds that don't involve me having to figure out how to
>> uninstall and re-install a different version?
>>
>> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:
>>
>> 3.9..
>>
>> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan 
>> wrote:
>>
>> Which version of C* ? There was similar issues with commitlogs in tic-toc
>> versions.
>>
>> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:
>>
>> I have a single node cassandra installation on my dev laptop, which is
>> used just for dev / testing.
>>
>> Recently, whenever I restart my laptop, Cassandra fails to start when I
>> run it via 'sudo service cassandra start'.
>>
>> Doing a tail on /var/log/cassandra/system.log gives this log:
>>
>> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
>> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
>> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
>> Exiting due to error while processing commit log during initialization.*
>> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>> Unexpected error deserializing mutation; saved to
>> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
>> mutation against a table with the same name but incompatible schema.
>> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
>> enough bytes to read 0th field board_id*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
>> [apache-cassandra-3.9.jar:3.9]*
>>
>>
>> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
>> fixes the problem, but then I lose all of my data.
>>
>> It looks like its saying there wasn't enough 

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Jonathan Haddad]

If you're not in prod *yet*, I once again recommend not using 3.9 for
anything serious.  Use the latest 3.0.x.

On Mon, Oct 24, 2016 at 6:19 PM Ali Akhtar  wrote:

> Stefania,
>
> As this is just on my dev laptop, what I'm really looking for is a quick
> 1-2 min fix to this solution that will act as a workaround.
>
> If I drop the keyspace and recreate it, will that fix this problem? Or do
> I need to uninstall 3.9 and go back to 3.7?
>
> I probably have made a couple of changes to the schema of the tables after
> I first created them.
>
> Happy to share the schema with you privately if it will lead to a 1-2 min
> fix to this problem for me.
>
> On Tue, Oct 25, 2016 at 5:59 AM, Stefania Alborghetti <
> stefania.alborghe...@datastax.com> wrote:
>
> Did the schema change? This would be 12397.
>
> If not, and if you don't mind sharing the data, or you have the steps to
> reproduce it, could you please open a ticket so it can be looked at? You
> need to attach the schema as well.
>
> On Mon, Oct 24, 2016 at 9:33 PM, Ali Akhtar  wrote:
>
> Its 'text'.  Don't know the answer of the 2nd question.
>
> On Mon, Oct 24, 2016 at 6:31 PM, Jonathan Haddad 
> wrote:
>
> What type is board id? Is the value a tombstone?
>
> On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:
>
> Thanks, but I did come across those, it doesn't look like they provide a
> resolution.
>
> On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan  wrote:
>
> You may read those:
>
> https://issues.apache.org/jira/browse/CASSANDRA-12121
> https://issues.apache.org/jira/browse/CASSANDRA-12397
>
> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar  wrote:
>
> Any workarounds that don't involve me having to figure out how to
> uninstall and re-install a different version?
>
> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:
>
> 3.9..
>
> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan  wrote:
>
> Which version of C* ? There was similar issues with commitlogs in tic-toc
> versions.
>
> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:
>
> I have a single node cassandra installation on my dev laptop, which is
> used just for dev / testing.
>
> Recently, whenever I restart my laptop, Cassandra fails to start when I
> run it via 'sudo service cassandra start'.
>
> Doing a tail on /var/log/cassandra/system.log gives this log:
>
> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
> Exiting due to error while processing commit log during initialization.*
> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
> enough bytes to read 0th field board_id*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
> [apache-cassandra-3.9.jar:3.9]*
>
>
> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which fixes
> the problem, but then I lose all of my data.
>
> It looks like its saying there wasn't enough data to read the field
> 'board_id', any ideas why that would be?
>
>
>
>
>
>
>
>
>
>
> --
>
>
> Stefania Alborghetti
>
> |+852 6114 9265| stefania.alborghe...@datastax.com
>
>
>

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Ali Akhtar]

Stefania,

As this is just on my dev laptop, what I'm really looking for is a quick
1-2 min fix to this solution that will act as a workaround.

If I drop the keyspace and recreate it, will that fix this problem? Or do I
need to uninstall 3.9 and go back to 3.7?

I probably have made a couple of changes to the schema of the tables after
I first created them.

Happy to share the schema with you privately if it will lead to a 1-2 min
fix to this problem for me.

On Tue, Oct 25, 2016 at 5:59 AM, Stefania Alborghetti <
stefania.alborghe...@datastax.com> wrote:

> Did the schema change? This would be 12397.
>
> If not, and if you don't mind sharing the data, or you have the steps to
> reproduce it, could you please open a ticket so it can be looked at? You
> need to attach the schema as well.
>
> On Mon, Oct 24, 2016 at 9:33 PM, Ali Akhtar  wrote:
>
>> Its 'text'.  Don't know the answer of the 2nd question.
>>
>> On Mon, Oct 24, 2016 at 6:31 PM, Jonathan Haddad 
>> wrote:
>>
>>> What type is board id? Is the value a tombstone?
>>>
>>> On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:
>>>
 Thanks, but I did come across those, it doesn't look like they provide
 a resolution.

 On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan 
 wrote:

 You may read those:

 https://issues.apache.org/jira/browse/CASSANDRA-12121
 https://issues.apache.org/jira/browse/CASSANDRA-12397

 On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar 
 wrote:

 Any workarounds that don't involve me having to figure out how to
 uninstall and re-install a different version?

 On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar 
 wrote:

 3.9..

 On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan 
 wrote:

 Which version of C* ? There was similar issues with commitlogs in
 tic-toc versions.

 On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar 
 wrote:

 I have a single node cassandra installation on my dev laptop, which is
 used just for dev / testing.

 Recently, whenever I restart my laptop, Cassandra fails to start when I
 run it via 'sudo service cassandra start'.

 Doing a tail on /var/log/cassandra/system.log gives this log:

 *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
 /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
 /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
 /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
 *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
 Exiting due to error while processing commit log during initialization.*
 *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
 Unexpected error deserializing mutation; saved to
 /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
 mutation against a table with the same name but incompatible schema.
 Exception follows: org.apache.cassandra.serializers.MarshalException: Not
 enough bytes to read 0th field board_id*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
 [apache-cassandra-3.9.jar:3.9]*


 I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
 fixes the problem, but then I lose all of my data.

 It looks like its saying there wasn't enough data to read the field
 'board_id', any ideas why that would be?







>>
>
>
> --
>
>
> Stefania Alborghetti
>
> |+852 6114 9265| 

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Stefania Alborghetti]

Did the schema change? This would be 12397.

If not, and if you don't mind sharing the data, or you have the steps to
reproduce it, could you please open a ticket so it can be looked at? You
need to attach the schema as well.

On Mon, Oct 24, 2016 at 9:33 PM, Ali Akhtar  wrote:

> Its 'text'.  Don't know the answer of the 2nd question.
>
> On Mon, Oct 24, 2016 at 6:31 PM, Jonathan Haddad 
> wrote:
>
>> What type is board id? Is the value a tombstone?
>>
>> On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:
>>
>>> Thanks, but I did come across those, it doesn't look like they provide a
>>> resolution.
>>>
>>> On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan 
>>> wrote:
>>>
>>> You may read those:
>>>
>>> https://issues.apache.org/jira/browse/CASSANDRA-12121
>>> https://issues.apache.org/jira/browse/CASSANDRA-12397
>>>
>>> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar 
>>> wrote:
>>>
>>> Any workarounds that don't involve me having to figure out how to
>>> uninstall and re-install a different version?
>>>
>>> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar 
>>> wrote:
>>>
>>> 3.9..
>>>
>>> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan 
>>> wrote:
>>>
>>> Which version of C* ? There was similar issues with commitlogs in
>>> tic-toc versions.
>>>
>>> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar 
>>> wrote:
>>>
>>> I have a single node cassandra installation on my dev laptop, which is
>>> used just for dev / testing.
>>>
>>> Recently, whenever I restart my laptop, Cassandra fails to start when I
>>> run it via 'sudo service cassandra start'.
>>>
>>> Doing a tail on /var/log/cassandra/system.log gives this log:
>>>
>>> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
>>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
>>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
>>> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
>>> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
>>> Exiting due to error while processing commit log during initialization.*
>>> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>>> Unexpected error deserializing mutation; saved to
>>> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
>>> mutation against a table with the same name but incompatible schema.
>>> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
>>> enough bytes to read 0th field board_id*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
>>> [apache-cassandra-3.9.jar:3.9]*
>>>
>>>
>>> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
>>> fixes the problem, but then I lose all of my data.
>>>
>>> It looks like its saying there wasn't enough data to read the field
>>> 'board_id', any ideas why that would be?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>


-- 


Stefania Alborghetti

|+852 6114 9265| stefania.alborghe...@datastax.com

Re: time series data model

[kurt Greaves]

On 20 October 2016 at 09:29, wxn...@zjqunshuo.com 
wrote:

> I do need to align the time windows to day bucket to prevent one row
> become too big, and event_time is timestamp since unix epoch. If I use
> bigint as type of event_time, can I do queries as you mentioned?


Yes.

Kurt Greaves
k...@instaclustr.com
www.instaclustr.com

Re: Question on write failures logs show Uncaught exception on thread Thread[MutationStage-1,5,main]

[George Webster]

thank you that is quite helpful

On Mon, Oct 24, 2016 at 11:00 PM, Edward Capriolo 
wrote:

> The driver will enforce a max batch size of 65k.
> This is an issue in versions of cassandra like 2.1.X. There are control
> variables for the logged and unlogged batch size. You may also have to
> tweak your commitlog size as well.
>
> I demonstrate this here:
> https://github.com/edwardcapriolo/ec/blob/master/src/test/java/Base/batch/
> BigBatches2_2_6_tweeked.java
>
> Latest tick-tock version I tried worked out of the box.
>
> The only drawback of batches is potential JVM pressure. I did some some
> permutations of memory settings with the tests above. You can get a feel
> for rate + batch size and the jvm pressure it causes.
>
> On Mon, Oct 24, 2016 at 4:10 PM, George Webster 
> wrote:
>
>> Hey cassandra users,
>>
>> When performing writes I have hit an issue where the server is unable to
>> perform writes. The logs show:
>>
>> WARN  [MutationStage-1] 2016-10-24 22:05:52,592
>> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on
>> thread Thread[MutationStage-1,5,main]: {}
>> java.lang.IllegalArgumentException: Mutation of 16.011MiB is too large
>> for the maximum size of 16.000MiB
>> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:220)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at 
>> org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:69)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at 
>> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> ~[na:1.8.0_101]
>> at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorSe
>> rvice$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>> ~[apache-cassandra-3.9.jar:3.9]
>> at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorSe
>> rvice$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>> [apache-cassandra-3.9.jar:3.9]
>> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
>> [apache-cassandra-3.9.jar:3.9]
>> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
>>
>>
>> Looking around on google I found this guide https://support.datastax
>> .com/hc/en-us/articles/207267063-Mutation-of-x-bytes-
>> is-too-large-for-the-maxiumum-size-of-y-
>> that states I can increase the commitlog_segment_size_in_mb to solve the
>> problem.
>>
>> However, I wanted to ask if their are any drawbacks to doing so.
>>
>> Thanks you for your guidance.
>>
>> Respectfully,
>> George
>>
>
>

Doing an upsert into a collection?

[Ali Akhtar]

Say I have this UDT:

*CREATE TYPE rating (*
* user text,*
* rating int*
*);*

And, I have this table:

*CREATE TABLE movie (*
* id text,*
* name text,*
* ratings list,*
* PRIMARY KEY ( id )*
*);*

Say a user 'bob' rated a movie as a 5. Is it possible to do something like
this:

*UPDATE movie set ratings.rating = 5 WHERE ratings.user = 'bob'*

And have that query either update bob's previous rating if he had already
rated, or have it insert a new Rating into the ratings w/ user = bob,
rating = 5?

If not, can this be achieved with a map instead of a list?

Thanks.

Re: Does anyone store larger values in Cassandra E.g. 500 KB?

[Jens Rantil]

If I would do this, I would have have two tables; chunks and data:

CREATE TABLE file_chunks {
  filename string,
  chunk int,
  size int, // Optional if you want to query the total size of a file.
  PRIMARY KEY (filename, chunk)
}

CREATE TABLE chunks {
  filename string,
  chunk int,
  data blob,
  PRIMARY KEY ((filename, chunk))
}

By keeping the data chunks in a separate table, you'd make sure to spread
the data more evenly across the cluster. If the size of the files differ in
a size this is a much better approach. Also, using `(filename, chunk)` in
`data` table makes it possible for you do have a background process that
makes sure to delete rows in `chunks` that no longer exist in `file_chunks`.

Jens

On Friday, October 21, 2016, jason zhao yang 
wrote:

> 1. usually before storing object, serialization is needed, so we can know
> the size.
> 2. add "chunk id" as last clustering key.
>
> Vikas Jaiman  >于2016年10月21日周五
> 下午11:46写道：
>
>> Thanks for your answer but I am just curious about:
>>
>> i)How do you identify the size of the object which you are going to chunk?
>>
>> ii) While reading or updating how it is going to read all those chunks?
>>
>> Vikas
>>
>> On Thu, Oct 20, 2016 at 9:25 PM, Justin Cameron > > wrote:
>>
>>> You can, but it is not really very efficient or cost-effective. You may
>>> encounter issues with streaming, repairs and compaction if you have very
>>> large blobs (100MB+), so try to keep them under 10MB if possible.
>>>
>>> I'd suggest storing blobs in something like Amazon S3 and keeping just
>>> the bucket name & blob id in Cassandra.
>>>
>>> On Thu, 20 Oct 2016 at 12:03 Vikas Jaiman >> > wrote:
>>>
 Hi,

 Normally people would like to store smaller values in Cassandra. Is
 there anyone using it to store for larger values (e.g 500KB or more) and if
 so what are the issues you are facing . I Would like to know the tweaks
 also which you are considering.

 Thanks,
 Vikas

>>> --
>>>
>>> Justin Cameron
>>>
>>> Senior Software Engineer | Instaclustr
>>>
>>>
>>>
>>>
>>> This email has been sent on behalf of Instaclustr Pty Ltd (Australia)
>>> and Instaclustr Inc (USA).
>>>
>>> This email and any attachments may contain confidential and legally
>>> privileged information.  If you are not the intended recipient, do not copy
>>> or disclose its content, but please reply to this email immediately and
>>> highlight the error to the sender and then immediately delete the message.
>>>
>>>
>>
>>
>> --
>>
>

-- 
Jens Rantil
Backend engineer
Tink AB

Email: jens.ran...@tink.se
Phone: +46 708 84 18 32
Web: www.tink.se

Facebook  Linkedin

 Twitter 

Re: Question about compaction strategy changes

[kurt Greaves]

On 24 October 2016 at 18:11, Seth Edwards  wrote:

> The other thought is that we currently have data mixed in that does not
> have a TTL and we are strongly considering putting this data in it's own
> table.


You should definitely do that. Having non-TTL'd data mixed in will result
in SSTables that don't expire because some small portion may be live data.
Plus mixed with the small number of compaction candidates, it could take a
long time for these types of SSTables to be compacted (possibly never).

Kurt Greaves
k...@instaclustr.com
www.instaclustr.com

Re: Question on write failures logs show Uncaught exception on thread Thread[MutationStage-1,5,main]

[Edward Capriolo]

The driver will enforce a max batch size of 65k.
This is an issue in versions of cassandra like 2.1.X. There are control
variables for the logged and unlogged batch size. You may also have to
tweak your commitlog size as well.

I demonstrate this here:
https://github.com/edwardcapriolo/ec/blob/master/src/test/java/Base/batch/BigBatches2_2_6_tweeked.java

Latest tick-tock version I tried worked out of the box.

The only drawback of batches is potential JVM pressure. I did some some
permutations of memory settings with the tests above. You can get a feel
for rate + batch size and the jvm pressure it causes.

On Mon, Oct 24, 2016 at 4:10 PM, George Webster  wrote:

> Hey cassandra users,
>
> When performing writes I have hit an issue where the server is unable to
> perform writes. The logs show:
>
> WARN  [MutationStage-1] 2016-10-24 22:05:52,592
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[MutationStage-1,5,main]: {}
> java.lang.IllegalArgumentException: Mutation of 16.011MiB is too large
> for the maximum size of 16.000MiB
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262)
> ~[apache-cassandra-3.9.jar:3.9]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493)
> ~[apache-cassandra-3.9.jar:3.9]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
> ~[apache-cassandra-3.9.jar:3.9]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215)
> ~[apache-cassandra-3.9.jar:3.9]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:220)
> ~[apache-cassandra-3.9.jar:3.9]
> at 
> org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:69)
> ~[apache-cassandra-3.9.jar:3.9]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[apache-cassandra-3.9.jar:3.9]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_101]
> at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorServ
> ice$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[apache-cassandra-3.9.jar:3.9]
> at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorServ
> ice$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [apache-cassandra-3.9.jar:3.9]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.9.jar:3.9]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
>
>
> Looking around on google I found this guide https://support.
> datastax.com/hc/en-us/articles/207267063-Mutation-
> of-x-bytes-is-too-large-for-the-maxiumum-size-of-y-
> that states I can increase the commitlog_segment_size_in_mb to solve the
> problem.
>
> However, I wanted to ask if their are any drawbacks to doing so.
>
> Thanks you for your guidance.
>
> Respectfully,
> George
>

Question on write failures logs show Uncaught exception on thread Thread[MutationStage-1,5,main]

[George Webster]

Hey cassandra users,

When performing writes I have hit an issue where the server is unable to
perform writes. The logs show:

WARN  [MutationStage-1] 2016-10-24 22:05:52,592
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[MutationStage-1,5,main]: {}
java.lang.IllegalArgumentException: Mutation of 16.011MiB is too large for
the maximum size of 16.000MiB
at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262)
~[apache-cassandra-3.9.jar:3.9]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493)
~[apache-cassandra-3.9.jar:3.9]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
~[apache-cassandra-3.9.jar:3.9]
at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215)
~[apache-cassandra-3.9.jar:3.9]
at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:220)
~[apache-cassandra-3.9.jar:3.9]
at
org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:69)
~[apache-cassandra-3.9.jar:3.9]
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
~[apache-cassandra-3.9.jar:3.9]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_101]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.9.jar:3.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.9.jar:3.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
[apache-cassandra-3.9.jar:3.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]


Looking around on google I found this guide
https://support.datastax.com/hc/en-us/articles/207267063-Mutation-of-x-bytes-is-too-large-for-the-maxiumum-size-of-y-
that states I can increase the commitlog_segment_size_in_mb to solve the
problem.

However, I wanted to ask if their are any drawbacks to doing so.

Thanks you for your guidance.

Respectfully,
George

Re: Question about compaction strategy changes

[Seth Edwards]

Thanks Jeff. We've been trying to find the optimal setting for our TWCS.
It's just two tables with only one of the tables being a factor. Initially
we set the window to an hour, and then increased it to a day. It still
seemed that there were lots of small sstables on disk. dozens of small db
files that were maybe only a few megabytes. These were all the most recent
sstables in the data directory. As we've increased the window size and the
tombstone_threshold we've seen the size of the newest db files on disk to
now be larger, as we would expect.

The total size of the table in question is between 500GB and 550GB on each
node. At certain intervals it seems that all nodes begin a cycle of
compactions and the number of pending tasks goes up. During this period we
can see the compactions use up maybe 100 or 200GB, sometimes more, and then
when everything finished, we gain most of that disk space back. We usually
have over 500GB free but it can trickle down to only 150GB free. I assume
solving this is about finding the optimal TWCS settings for our TTL data.

The other thought is that we currently have data mixed in that does not
have a TTL and we are strongly considering putting this data in it's own
table.

On Mon, Oct 24, 2016 at 6:38 AM, Jeff Jirsa 
wrote:

>
>
> If you drop window size, you may force some window-major compactions (if
> you go from 1 week windows to 1 day windows, you’ll have 6 days worth of
> files start compacting into 1-day sstables).
>
> If you increase window size, you’ll likely have adjacent windows join (if
> you go from 1 day windows to 2 day windows, nearly every sstable will be
> joined with the one in the day adjacent to it).
>
>
>
> Short of altering compaction strategies, it seems unlikely that you’d see
> huge jumps where you’d run out of space. How many tables/CFs have TWCS
> enabled? How much space are you using, and how much is free?  Do you have
> hundreds with the same TWCS parameters?
>
>
>
> If you’re running very close to your capacity, you may want to consider
> dropping concurrent compactors down so fewer compaction tasks run at the
> same time. That will translate proportionally to the amount of extra disk
> you have consumed by compaction in a TWCS setting.
>
>
>
>
>
>
>
> *From: *Seth Edwards 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Sunday, October 23, 2016 at 7:03 PM
> *To: *user 
> *Subject: *Re: Question about compaction strategy changes
>
>
>
> More compactions meaning "rows to be compacted" or actual number of
> pending compactions? I assumed when I run nodetool compactionstats the
> number of pending tasks would line up with number of sstables that will be
> compacted. Most of the time this is idle, then we hit spots when it could
> jump into the thousands and we and up being short of a few hundred GB of
> disk space.
>
>
>
> On Sun, Oct 23, 2016 at 5:49 PM, kurt Greaves 
> wrote:
>
>
>
> On 22 October 2016 at 03:37, Seth Edwards  wrote:
>
> We're using TWCS and we notice that if we make changes to the options to
> the window unit or size, it seems to implicitly start recompacting all
> sstables.
>
>
>
> If you increase the window unit or size you potentially increase the
> number of SSTable candidates for compaction inside each window, which is
> why you would see more compactions. If you decrease the window you
> shouldn't see any new compactions kicked off, however be aware that you
> will have SSTables covering multiple windows, so until a full cycle of your
> TTL passes your read queries won't benefit from the smaller window size.
>
>
> Kurt Greaves
>
> k...@instaclustr.com
>
> www.instaclustr.com
> 
>
>
> CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and
> may be legally privileged. If you are not the intended recipient, do not
> disclose, copy, distribute, or use this email or any attachments. If you
> have received this in error please let the sender know and then delete the
> email and all attachments.
>

Re: incremental repairs with -pr flag?

[Alexander Dejanovski]

Hi Sean,

In order to mitigate its impact, anticompaction is not fully executed when
incremental repair is run with -pr. What you'll observe is that running
repair on all nodes with -pr will leave sstables marked as unrepaired on
all of them.

Then, if you think about it you realize it's no big deal as -pr is useless
with incremental repair : data is repaired only once with incremental
repair, which is what -pr intended to fix on full repair, by repairing all
token ranges only once instead of times the replication factor.

Cheers,

Le lun. 24 oct. 2016 18:05, Sean Bridges  a
écrit :

> Hey,
>
> In the datastax documentation on repair [1], it says,
>
> "The partitioner range option is recommended for routine maintenance. Do
> not use it to repair a downed node. Do not use with incremental repair
> (default for Cassandra 3.0 and later)."
>
> Why is it not recommended to use -pr with incremental repairs?
>
> Thanks,
>
> Sean
>
> [1]
> https://docs.datastax.com/en/cassandra/3.x/cassandra/operations/opsRepairNodesManualRepair.html
> --
>
> Sean Bridges
>
> senior systems architect
> Global Relay
>
> *sean.brid...@globalrelay.net* 
>
> *866.484.6630 *
> New York | Chicago | Vancouver | London (+44.0800.032.9829) | Singapore
> (+65.3158.1301)
>
> Global Relay Archive supports email, instant messaging, BlackBerry,
> Bloomberg, Thomson Reuters, Pivot, YellowJacket, LinkedIn, Twitter,
> Facebook and more.
>
> Ask about *Global Relay Message*
>  - The Future of
> Collaboration in the Financial Services World
>
> All email sent to or from this address will be retained by Global Relay's
> email archiving system. This message is intended only for the use of the
> individual or entity to which it is addressed, and may contain information
> that is privileged, confidential, and exempt from disclosure under
> applicable law. Global Relay will not be liable for any compliance or
> technical information provided herein. All trademarks are the property of
> their respective owners.
>
> --
-
Alexander Dejanovski
France
@alexanderdeja

Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

incremental repairs with -pr flag?

[Sean Bridges]

Hey,

In the datastax documentation on repair [1], it says,

"The partitioner range option is recommended for routine maintenance. Do 
not use it to repair a downed node. Do not use with incremental repair 
(default for Cassandra 3.0 and later)."


Why is it not recommended to use -pr with incremental repairs?

Thanks,

Sean


[1] 
https://docs.datastax.com/en/cassandra/3.x/cassandra/operations/opsRepairNodesManualRepair.html

--

Sean Bridges

senior systems architect
Global Relay

_sean.bridges@globalrelay.net_ 

*866.484.6630 *
New York | Chicago | Vancouver | London (+44.0800.032.9829) | Singapore 
(+65.3158.1301)


Global Relay Archive supports email, instant messaging, BlackBerry, 
Bloomberg, Thomson Reuters, Pivot, YellowJacket, LinkedIn, Twitter, 
Facebook and more.


Ask about *_Global Relay Message_* 
 - The Future of 
Collaboration in the Financial Services World


All email sent to or from this address will be retained by Global 
Relay's email archiving system. This message is intended only for the 
use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential, and exempt from 
disclosure under applicable law. Global Relay will not be liable for any 
compliance or technical information provided herein. All trademarks are 
the property of their respective owners.

Re: Error creating pool to /IP_ADDRESS33:9042 (Proving Cassandra's NO SINGLE point of failure)

[Vladimir Yudovin]

Probably used Python driver can't restart failed operation with connection to 
other node. Do you provide all three IPs to Python driver for connecting?



Best regards, Vladimir Yudovin, 

Winguzone - Hosted Cloud Cassandra
Launch your cluster in minutes.





 On Mon, 24 Oct 2016 07:48:05 -0400Rajesh Radhakrishnan 
rajesh.radhakrish...@phe.gov.uk wrote 




Hi,

 

 I have  3 nodes Cassandra cluster.

 Cassandra version : dsc-cassandra-2.1.5

 Python Cassandra Driver : 2.5.1

 

 Running the nodes in Red Hat virtual machines.

 

 Node ip info: 

 Node 1: IP_ADDRESS219

 Node 2: IP_ADDRESS229

 Node 3: IP_ADDRESS230

 

 

 (IP_ADDRESS219 is masked for this email which represents something similar 
123.321.123.219)

 

 

Cassandra.yaml configuration details of node1:

 

 listen_address: IP_ADDRESS219

 broadcast_address: commented

 rpc_address: IP_ADDRESS219

 broadcast_rpc_address : commented

 

 The IP address of the node is ( using the ifconfig command ) IP_ADDRESS219.

 

 While the cluster is up and running , when I put Node 3 (IP_ADDRESS230) down, 
I was able to connect to CQLSH from IP_ADDRESS219 and IP_ADDRESS229. 

 

 But while I was running a Python script which just reads data from Cassandra 
using the cassandra-python-driver, and when the Node 3 stops(while the script 
is still running I intentionally stops  node3).

 

 Then the script comes to a halt with OperationTimedOut: errors={}, last_host= 
IP_ADDRESS219.

 

 However if I run the script when node3 is already down, it runs and reads data.

 

 So during the reading operation  if any of the nodes in the cluster goes down 
its affects the client operation??? Does anyone has similar situation. 

 

 Here we are trying to establish or prove Cassandra's always on (NO single 
point of failure).  Do you know why this is happening Thank you .

 

 



Kind regards,
 Rajesh R















**

 The information contained in the EMail and any attachments is confidential and 
intended solely and for the attention and use of the named addressee(s). It may 
not be disclosed to any other person without the express authority of Public 
Health England, or the intended recipient, or both. If you are not the intended 
recipient, you must not disclose, copy, distribute or retain this message or 
any part of it. This footnote also confirms that this EMail has been swept for 
computer viruses by Symantec.Cloud, but please re-sweep any attachments before 
opening or saving. http://www.gov.uk/PHE

 **

Re: Question about compaction strategy changes

[Jeff Jirsa]

 

If you drop window size, you may force some window-major compactions (if you go 
from 1 week windows to 1 day windows, you’ll have 6 days worth of files start 
compacting into 1-day sstables).

If you increase window size, you’ll likely have adjacent windows join (if you 
go from 1 day windows to 2 day windows, nearly every sstable will be joined 
with the one in the day adjacent to it).

 

Short of altering compaction strategies, it seems unlikely that you’d see huge 
jumps where you’d run out of space. How many tables/CFs have TWCS enabled? How 
much space are you using, and how much is free?  Do you have hundreds with the 
same TWCS parameters? 

 

If you’re running very close to your capacity, you may want to consider 
dropping concurrent compactors down so fewer compaction tasks run at the same 
time. That will translate proportionally to the amount of extra disk you have 
consumed by compaction in a TWCS setting. 

 

 

 

From: Seth Edwards 
Reply-To: "user@cassandra.apache.org" 
Date: Sunday, October 23, 2016 at 7:03 PM
To: user 
Subject: Re: Question about compaction strategy changes

 

More compactions meaning "rows to be compacted" or actual number of pending 
compactions? I assumed when I run nodetool compactionstats the number of 
pending tasks would line up with number of sstables that will be compacted. 
Most of the time this is idle, then we hit spots when it could jump into the 
thousands and we and up being short of a few hundred GB of disk space. 

 

On Sun, Oct 23, 2016 at 5:49 PM, kurt Greaves  wrote:

 

On 22 October 2016 at 03:37, Seth Edwards  wrote:

We're using TWCS and we notice that if we make changes to the options to the 
window unit or size, it seems to implicitly start recompacting all sstables.

 

If you increase the window unit or size you potentially increase the number of 
SSTable candidates for compaction inside each window, which is why you would 
see more compactions. If you decrease the window you shouldn't see any new 
compactions kicked off, however be aware that you will have SSTables covering 
multiple windows, so until a full cycle of your TTL passes your read queries 
won't benefit from the smaller window size.


Kurt Greaves 

k...@instaclustr.com

www.instaclustr.com

 

CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may 
be legally privileged. If you are not the intended recipient, do not disclose, 
copy, distribute, or use this email or any attachments. If you have received 
this in error please let the sender know and then delete the email and all 
attachments.


smime.p7s
Description: S/MIME cryptographic signature

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Ali Akhtar]

Its 'text'.  Don't know the answer of the 2nd question.

On Mon, Oct 24, 2016 at 6:31 PM, Jonathan Haddad  wrote:

> What type is board id? Is the value a tombstone?
>
> On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:
>
>> Thanks, but I did come across those, it doesn't look like they provide a
>> resolution.
>>
>> On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan 
>> wrote:
>>
>> You may read those:
>>
>> https://issues.apache.org/jira/browse/CASSANDRA-12121
>> https://issues.apache.org/jira/browse/CASSANDRA-12397
>>
>> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar 
>> wrote:
>>
>> Any workarounds that don't involve me having to figure out how to
>> uninstall and re-install a different version?
>>
>> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:
>>
>> 3.9..
>>
>> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan 
>> wrote:
>>
>> Which version of C* ? There was similar issues with commitlogs in tic-toc
>> versions.
>>
>> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:
>>
>> I have a single node cassandra installation on my dev laptop, which is
>> used just for dev / testing.
>>
>> Recently, whenever I restart my laptop, Cassandra fails to start when I
>> run it via 'sudo service cassandra start'.
>>
>> Doing a tail on /var/log/cassandra/system.log gives this log:
>>
>> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
>> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
>> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
>> Exiting due to error while processing commit log during initialization.*
>> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>> Unexpected error deserializing mutation; saved to
>> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
>> mutation against a table with the same name but incompatible schema.
>> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
>> enough bytes to read 0th field board_id*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
>> [apache-cassandra-3.9.jar:3.9]*
>>
>>
>> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
>> fixes the problem, but then I lose all of my data.
>>
>> It looks like its saying there wasn't enough data to read the field
>> 'board_id', any ideas why that would be?
>>
>>
>>
>>
>>
>>
>>

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Jonathan Haddad]

What type is board id? Is the value a tombstone?
On Mon, Oct 24, 2016 at 1:38 AM Ali Akhtar  wrote:

> Thanks, but I did come across those, it doesn't look like they provide a
> resolution.
>
> On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan  wrote:
>
> You may read those:
>
> https://issues.apache.org/jira/browse/CASSANDRA-12121
> https://issues.apache.org/jira/browse/CASSANDRA-12397
>
> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar  wrote:
>
> Any workarounds that don't involve me having to figure out how to
> uninstall and re-install a different version?
>
> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:
>
> 3.9..
>
> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan  wrote:
>
> Which version of C* ? There was similar issues with commitlogs in tic-toc
> versions.
>
> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:
>
> I have a single node cassandra installation on my dev laptop, which is
> used just for dev / testing.
>
> Recently, whenever I restart my laptop, Cassandra fails to start when I
> run it via 'sudo service cassandra start'.
>
> Doing a tail on /var/log/cassandra/system.log gives this log:
>
> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
> Exiting due to error while processing commit log during initialization.*
> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
> enough bytes to read 0th field board_id*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
> [apache-cassandra-3.9.jar:3.9]*
>
>
> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which fixes
> the problem, but then I lose all of my data.
>
> It looks like its saying there wasn't enough data to read the field
> 'board_id', any ideas why that would be?
>
>
>
>
>
>
>

Re: Transparent Fail-Over for Java Driver to survive Cluster Rolling

[Hannu Kröger]

Hi,

QUORUM would go through if only one node is down any given time.

Depending on the consistency requirements of your application, you could also 
use ONE (or LOCAL_ONE) as well for sensor reading storage. That would go 
through even if two nodes are down any given time.

BR,
Hannu

> On 24 Oct 2016, at 15:27, Andreas Fritzler  wrote:
> 
> Thanks a lot Hannu! 
> 
> How about the write path though. What consistency level would I choose if I 
> want to insert e.g. sensor data into my cluster without the app crashing 
> every time I up update the cluster? I would assume that QUORUM (replication 
> of 3) might not always go through?
> 
> 
> 
> On Mon, Oct 24, 2016 at 2:09 PM, Hannu Kröger  > wrote:
> Hi,
> 
> Once the client is connected, it will automatically connect to many nodes in 
> the cluster. Therefore once the app is running the amount of contact points 
> doesn’t matter and if you have consistency level < ALL (or QUORUM where 
> replication factor is <= 2), your app should tolerate rolling restart ok.
> 
> That being said, you should have more than one contact point because if you 
> restart your application and the node indicated in contact point happens to 
> be down, the application cannot connect to cluster and fails. Having two 
> contact points is a good start.
> 
> Cheers,
> Hannu
> 
> 
>> On 24 Oct 2016, at 15:04, Andreas Fritzler > > wrote:
>> 
>> Hi,
>> 
>> I was wondering if it is enough to set a list of contact points via:
>> 
>> Cluster.builder().addContactPoint("host1").addContactPoint("host2")...;
>> to survive a cluster rolling while inserting/reading from the cluster.
>> 
>> Regards,
>> Andreas
> 
> 

Re: Transparent Fail-Over for Java Driver to survive Cluster Rolling

[Andreas Fritzler]

Thanks a lot Hannu!

How about the write path though. What consistency level would I choose if I
want to insert e.g. sensor data into my cluster without the app crashing
every time I up update the cluster? I would assume that QUORUM (replication
of 3) might not always go through?



On Mon, Oct 24, 2016 at 2:09 PM, Hannu Kröger  wrote:

> Hi,
>
> Once the client is connected, it will automatically connect to many nodes
> in the cluster. Therefore once the app is running the amount of contact
> points doesn’t matter and if you have consistency level < ALL (or QUORUM
> where replication factor is <= 2), your app should tolerate rolling restart
> ok.
>
> That being said, you should have more than one contact point because if
> you restart your application and the node indicated in contact point
> happens to be down, the application cannot connect to cluster and fails.
> Having two contact points is a good start.
>
> Cheers,
> Hannu
>
>
> On 24 Oct 2016, at 15:04, Andreas Fritzler 
> wrote:
>
> Hi,
>
> I was wondering if it is enough to set a list of contact points via:
>
> Cluster.builder().addContactPoint("host1").addContactPoint("host2")...;
>
> to survive a cluster rolling while inserting/reading from the cluster.
>
> Regards,
> Andreas
>
>
>

Re: Transparent Fail-Over for Java Driver to survive Cluster Rolling

[Hannu Kröger]

Hi,

Once the client is connected, it will automatically connect to many nodes in 
the cluster. Therefore once the app is running the amount of contact points 
doesn’t matter and if you have consistency level < ALL (or QUORUM where 
replication factor is <= 2), your app should tolerate rolling restart ok.

That being said, you should have more than one contact point because if you 
restart your application and the node indicated in contact point happens to be 
down, the application cannot connect to cluster and fails. Having two contact 
points is a good start.

Cheers,
Hannu


> On 24 Oct 2016, at 15:04, Andreas Fritzler  wrote:
> 
> Hi,
> 
> I was wondering if it is enough to set a list of contact points via:
> 
> Cluster.builder().addContactPoint("host1").addContactPoint("host2")...;
> to survive a cluster rolling while inserting/reading from the cluster.
> 
> Regards,
> Andreas

Transparent Fail-Over for Java Driver to survive Cluster Rolling

[Andreas Fritzler]

Hi,

I was wondering if it is enough to set a list of contact points via:

Cluster.builder().addContactPoint("host1").addContactPoint("host2")...;

to survive a cluster rolling while inserting/reading from the cluster.

Regards,
Andreas

Error creating pool to /IP_ADDRESS33:9042 (Proving Cassandra's NO SINGLE point of failure)

[Rajesh Radhakrishnan]

Hi,

I have  3 nodes Cassandra cluster.
Cassandra version : dsc-cassandra-2.1.5
Python Cassandra Driver : 2.5.1

Running the nodes in Red Hat virtual machines.

Node ip info:
Node 1: IP_ADDRESS219
Node 2: IP_ADDRESS229
Node 3: IP_ADDRESS230


(IP_ADDRESS219 is masked for this email which represents something similar 
123.321.123.219)

Cassandra.yaml configuration details of node1:

listen_address: IP_ADDRESS219
broadcast_address: commented
rpc_address: IP_ADDRESS219
broadcast_rpc_address : commented

The IP address of the node is ( using the ifconfig command ) IP_ADDRESS219.

While the cluster is up and running , when I put Node 3 (IP_ADDRESS230) down, I 
was able to connect to CQLSH from IP_ADDRESS219 and IP_ADDRESS229.

But while I was running a Python script which just reads data from Cassandra 
using the cassandra-python-driver, and when the Node 3 stops(while the script 
is still running I intentionally stops  node3).

Then the script comes to a halt with OperationTimedOut: errors={}, last_host= 
IP_ADDRESS219.

However if I run the script when node3 is already down, it runs and reads data.

So during the reading operation  if any of the nodes in the cluster goes down 
its affects the client operation??? Does anyone has similar situation.

Here we are trying to establish or prove Cassandra's always on (NO single point 
of failure).  Do you know why this is happening Thank you .


Kind regards,
Rajesh R


**
The information contained in the EMail and any attachments is confidential and 
intended solely and for the attention and use of the named addressee(s). It may 
not be disclosed to any other person without the express authority of Public 
Health England, or the intended recipient, or both. If you are not the intended 
recipient, you must not disclose, copy, distribute or retain this message or 
any part of it. This footnote also confirms that this EMail has been swept for 
computer viruses by Symantec.Cloud, but please re-sweep any attachments before 
opening or saving. http://www.gov.uk/PHE
**

Re: Lightweight transaction inside a batch : request rejected

[DuyHai Doan]

"So I guess in that case the Paxos operation does not span multiple table
but operates only the table that has the condition. Am I wrong?"

--> The fact that you're using a BATCH with LWT means that either ALL
statements succeed or NONE. And to guarantee this, Paxos ballot must cover
all statements. In your case since they span on multiple tables it's not
possible

On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delanoë 
wrote:

> Thanks DuyHai for the info.
> I already see this JIRA, however the use case I describe is slightly
> different from the JIRA as there is only ONE condition on ONE table. Other
> statements of the batch does not have any condition.
> So I guess in that case the Paxos operation does not span multiple table
> but operates only the table that has the condition. Am I wrong?
>
>
>
> 2016-10-24 10:21 GMT+02:00 DuyHai Doan :
>
>> As far as I remember, there is an optimization in Cassandra to manage
>> Paxos ballot per table. So asking a Paxos operation to span multiple tables
>> (even if same partition key) would require a lot of changes in the current
>> impl.
>>
>> The question has already been raised, you may want to convince the
>> committers by adding some comments here: https://issues.apache.or
>> g/jira/browse/CASSANDRA-10085
>>
>> On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë 
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to use lightweight transaction inside a batch but the
>>> request is rejected by cassandra, however I think this is a use case than
>>> could be handled without problem.
>>> Below is what I wanted to do.
>>>
>>> I am using cassandra 3.7.
>>>
>>> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
>>> 'replication_factor': '1'};
>>>
>>> CREATE TABLE test_ksp.item (
>>> user_id bigint,
>>> item_id text,
>>> item_value text,
>>> item_key1 text,
>>> item_key2 text,
>>> PRIMARY KEY ((user_id), item_id));
>>>
>>> CREATE TABLE test_ksp.item_id_by_key (
>>> user_id bigint,
>>> item_key text,
>>> item_id text,
>>> PRIMARY KEY ((user_id), item_key));
>>>
>>> USE test_ksp;
>>>
>>> BEGIN BATCH
>>> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
>>> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
>>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>>> 'key-XYZ-123', 'i11');
>>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>>> 'key-ABC-789', 'i11');
>>> APPLY BATCH;
>>>
>>>
>>> So as you can see this is a batch that targets 2 tables but with the
>>> same partition key (i.e the same target nodes). Moreover It uses only ONE
>>> condition on one table only.
>>> I don't understand why cassandra returns an error "Batch with conditions
>>> cannot span multiple tables" in that case.
>>>
>>> I understand that if I had used several conditions on different tables
>>> it could be a problem, but in my case there is only one condition and
>>> moreover I have always the same partition key for every table inside the
>>> batch.
>>> As there is only one condition, I expected the paxos protocol just act
>>> on this condition and as the partition keys are all the same, the paxos
>>> protocol has only to work with the same replica nodes (not span across
>>> multiple partition).
>>> In my point of view this is as if the LWT was in a single statement,
>>> except that after the LWT is accepted a complete batch has to be executed.
>>>
>>> Is there someone that could explain why this use case need to be
>>> rejected by cassandra? And do you think this is something that cassandra
>>> could handle in a future version ?
>>>
>>> Regards,
>>> Mickaël
>>>
>>>
>>
>
>
> --
> Mickaël Delanoë
>

Re: Does anyone store larger values in Cassandra E.g. 500 KB?

[Vikas Jaiman]

Thanks. I will have a look into that.


Vikas

On Fri, Oct 21, 2016 at 7:18 PM, jason zhao yang <
zhaoyangsingap...@gmail.com> wrote:

> 1. usually before storing object, serialization is needed, so we can know
> the size.
> 2. add "chunk id" as last clustering key.
>
> Vikas Jaiman 于2016年10月21日周五 下午11:46写道：
>
>> Thanks for your answer but I am just curious about:
>>
>> i)How do you identify the size of the object which you are going to chunk?
>>
>> ii) While reading or updating how it is going to read all those chunks?
>>
>> Vikas
>>
>> On Thu, Oct 20, 2016 at 9:25 PM, Justin Cameron 
>> wrote:
>>
>> You can, but it is not really very efficient or cost-effective. You may
>> encounter issues with streaming, repairs and compaction if you have very
>> large blobs (100MB+), so try to keep them under 10MB if possible.
>>
>> I'd suggest storing blobs in something like Amazon S3 and keeping just
>> the bucket name & blob id in Cassandra.
>>
>> On Thu, 20 Oct 2016 at 12:03 Vikas Jaiman 
>> wrote:
>>
>> Hi,
>>
>> Normally people would like to store smaller values in Cassandra. Is there
>> anyone using it to store for larger values (e.g 500KB or more) and if so
>> what are the issues you are facing . I Would like to know the tweaks also
>> which you are considering.
>>
>> Thanks,
>> Vikas
>>
>> --
>>
>> Justin Cameron
>>
>> Senior Software Engineer | Instaclustr
>>
>>
>>
>>
>> This email has been sent on behalf of Instaclustr Pty Ltd (Australia) and
>> Instaclustr Inc (USA).
>>
>> This email and any attachments may contain confidential and legally
>> privileged information.  If you are not the intended recipient, do not copy
>> or disclose its content, but please reply to this email immediately and
>> highlight the error to the sender and then immediately delete the message.
>>
>>
>>
>>
>> --
>>
>

Re: Hadoop vs Cassandra

[Stefania Alborghetti]

If you intend to use files on HDFS, I would recommend using Parquet files.
It's a very fast columnar format that allows querying data very
efficiently. I believe a Spark data frame will take care of saving all the
columns in a Parquet file. So you could extract the data from Cassandra via
the Spark connector and save it to Parquet.

Or you can query Cassandra data directly from Spark, but it won't be as
fast as Parquet.

It's a trade-off between how much data to save to Parquet, how often, how
many queries, what format and whether you can tolerate some stale data.


On Sun, Oct 23, 2016 at 7:18 PM, Welly Tambunan  wrote:

> Another thing is,
>
> Let's say that we already have a structure data, the way we load that to
> HDFS is to turn that one into a files ?
>
> Cheers
>
> On Sun, Oct 23, 2016 at 6:18 PM, Welly Tambunan  wrote:
>
>> So basically you will store that files to HDFS and use Spark to process
>> it ?
>>
>> On Sun, Oct 23, 2016 at 6:03 PM, Joaquin Alzola <
>> joaquin.alz...@lebara.com> wrote:
>>
>>>
>>>
>>> I think what Ali mentions is correct:
>>>
>>> If you need a lot of queries that require joins, or complex analytics of
>>> the kind that Cassandra isn't suited for, then HDFS / HBase may be better.
>>>
>>>
>>>
>>> We have files in which one line contains 500 fields (separated by pipe)
>>> and each of this fields is particularly important.
>>>
>>> Cassandra will not manage that since you will need 500 indexes. HDFS is
>>> the proper way.
>>>
>>>
>>>
>>>
>>>
>>> *From:* Welly Tambunan [mailto:if05...@gmail.com]
>>> *Sent:* 23 October 2016 10:19
>>> *To:* user@cassandra.apache.org
>>> *Subject:* Re: Hadoop vs Cassandra
>>>
>>>
>>>
>>> I like muti data centre resillience in cassandra.
>>>
>>> I think thats plus one for cassandra.
>>>
>>> Ali, complex analytics can be done in spark right?
>>>
>>> On 23 Oct 2016 4:08 p.m., "Ali Akhtar"  wrote:
>>>
>>> >
>>>
>>> > I would say it depends on your use case.
>>> >
>>> > If you need a lot of queries that require joins, or complex analytics
>>> of the kind that Cassandra isn't suited for, then HDFS / HBase may be
>>> better.
>>> >
>>> > If you can work with the cassandra way of doing things (creating new
>>> tables for each query you'll need to do, duplicating data - doing extra
>>> writes for faster reads) , then Cassandra should work for you. It is easier
>>> to setup and do dev ops with, in my experience.
>>> >
>>> > On Sun, Oct 23, 2016 at 2:05 PM, Welly Tambunan 
>>> wrote:
>>>
>>> >>
>>>
>>> >> I mean. HDFS and HBase.
>>> >>
>>> >> On Sun, Oct 23, 2016 at 4:00 PM, Ali Akhtar 
>>> wrote:
>>>
>>> >>>
>>>
>>> >>> By Hadoop do you mean HDFS?
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sun, Oct 23, 2016 at 1:56 PM, Welly Tambunan 
>>> wrote:
>>>
>>> 
>>>
>>>  Hi All,
>>> 
>>>  I read the following comparison between hadoop and cassandra. Seems
>>> the conclusion that we use hadoop for data lake ( cold data ) and Cassandra
>>> for hot data (real time data).
>>> 
>>>  http://www.datastax.com/nosql-databases/nosql-cassandra-and-hadoop
>>> 
>>> 
>>>  My question is, can we just use cassandra to rule them all ?
>>> 
>>>  What we are trying to achieve is to minimize the moving part on our
>>> system.
>>> 
>>>  Any response would be really appreciated.
>>> 
>>> 
>>>  Cheers
>>> 
>>>  --
>>>  Welly Tambunan
>>>  Triplelands
>>> 
>>>  http://weltam.wordpress.com 
>>>  http://www.triplelands.com 
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Welly Tambunan
>>> >> Triplelands
>>> >>
>>> >> http://weltam.wordpress.com 
>>> >> http://www.triplelands.com 
>>> >
>>> >
>>> This email is confidential and may be subject to privilege. If you are
>>> not the intended recipient, please do not copy or disclose its content but
>>> contact the sender immediately upon receipt.
>>>
>>
>>
>>
>> --
>> Welly Tambunan
>> Triplelands
>>
>> http://weltam.wordpress.com
>> http://www.triplelands.com 
>>
>
>
>
> --
> Welly Tambunan
> Triplelands
>
> http://weltam.wordpress.com
> http://www.triplelands.com 
>



-- 


Stefania Alborghetti

|+852 6114 9265| stefania.alborghe...@datastax.com

Re: Lightweight transaction inside a batch : request rejected

[Mickael Delanoë]

Thanks DuyHai for the info.
I already see this JIRA, however the use case I describe is slightly
different from the JIRA as there is only ONE condition on ONE table. Other
statements of the batch does not have any condition.
So I guess in that case the Paxos operation does not span multiple table
but operates only the table that has the condition. Am I wrong?



2016-10-24 10:21 GMT+02:00 DuyHai Doan :

> As far as I remember, there is an optimization in Cassandra to manage
> Paxos ballot per table. So asking a Paxos operation to span multiple tables
> (even if same partition key) would require a lot of changes in the current
> impl.
>
> The question has already been raised, you may want to convince the
> committers by adding some comments here: https://issues.apache.
> org/jira/browse/CASSANDRA-10085
>
> On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë 
> wrote:
>
>> Hi,
>>
>> I would like to use lightweight transaction inside a batch but the
>> request is rejected by cassandra, however I think this is a use case than
>> could be handled without problem.
>> Below is what I wanted to do.
>>
>> I am using cassandra 3.7.
>>
>> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
>> 'replication_factor': '1'};
>>
>> CREATE TABLE test_ksp.item (
>> user_id bigint,
>> item_id text,
>> item_value text,
>> item_key1 text,
>> item_key2 text,
>> PRIMARY KEY ((user_id), item_id));
>>
>> CREATE TABLE test_ksp.item_id_by_key (
>> user_id bigint,
>> item_key text,
>> item_id text,
>> PRIMARY KEY ((user_id), item_key));
>>
>> USE test_ksp;
>>
>> BEGIN BATCH
>> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
>> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>> 'key-XYZ-123', 'i11');
>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>> 'key-ABC-789', 'i11');
>> APPLY BATCH;
>>
>>
>> So as you can see this is a batch that targets 2 tables but with the same
>> partition key (i.e the same target nodes). Moreover It uses only ONE
>> condition on one table only.
>> I don't understand why cassandra returns an error "Batch with conditions
>> cannot span multiple tables" in that case.
>>
>> I understand that if I had used several conditions on different tables it
>> could be a problem, but in my case there is only one condition and moreover
>> I have always the same partition key for every table inside the batch.
>> As there is only one condition, I expected the paxos protocol just act on
>> this condition and as the partition keys are all the same, the paxos
>> protocol has only to work with the same replica nodes (not span across
>> multiple partition).
>> In my point of view this is as if the LWT was in a single statement,
>> except that after the LWT is accepted a complete batch has to be executed.
>>
>> Is there someone that could explain why this use case need to be rejected
>> by cassandra? And do you think this is something that cassandra could
>> handle in a future version ?
>>
>> Regards,
>> Mickaël
>>
>>
>


-- 
Mickaël Delanoë

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Ali Akhtar]

Thanks, but I did come across those, it doesn't look like they provide a
resolution.

On Mon, Oct 24, 2016 at 1:36 PM, DuyHai Doan  wrote:

> You may read those:
>
> https://issues.apache.org/jira/browse/CASSANDRA-12121
> https://issues.apache.org/jira/browse/CASSANDRA-12397
>
> On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar  wrote:
>
>> Any workarounds that don't involve me having to figure out how to
>> uninstall and re-install a different version?
>>
>> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:
>>
>>> 3.9..
>>>
>>> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan 
>>> wrote:
>>>
 Which version of C* ? There was similar issues with commitlogs in
 tic-toc versions.

 On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar 
 wrote:

> I have a single node cassandra installation on my dev laptop, which is
> used just for dev / testing.
>
> Recently, whenever I restart my laptop, Cassandra fails to start when
> I run it via 'sudo service cassandra start'.
>
> Doing a tail on /var/log/cassandra/system.log gives this log:
>
> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
> Exiting due to error while processing commit log during initialization.*
> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
> enough bytes to read 0th field board_id*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
> [apache-cassandra-3.9.jar:3.9]*
>
>
> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
> fixes the problem, but then I lose all of my data.
>
> It looks like its saying there wasn't enough data to read the field
> 'board_id', any ideas why that would be?
>


>>>
>>
>

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[DuyHai Doan]

You may read those:

https://issues.apache.org/jira/browse/CASSANDRA-12121
https://issues.apache.org/jira/browse/CASSANDRA-12397

On Mon, Oct 24, 2016 at 10:24 AM, Ali Akhtar  wrote:

> Any workarounds that don't involve me having to figure out how to
> uninstall and re-install a different version?
>
> On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:
>
>> 3.9..
>>
>> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan 
>> wrote:
>>
>>> Which version of C* ? There was similar issues with commitlogs in
>>> tic-toc versions.
>>>
>>> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar 
>>> wrote:
>>>
 I have a single node cassandra installation on my dev laptop, which is
 used just for dev / testing.

 Recently, whenever I restart my laptop, Cassandra fails to start when I
 run it via 'sudo service cassandra start'.

 Doing a tail on /var/log/cassandra/system.log gives this log:

 *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
 /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
 /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
 /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
 *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
 Exiting due to error while processing commit log during initialization.*
 *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
 Unexpected error deserializing mutation; saved to
 /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
 mutation against a table with the same name but incompatible schema.
 Exception follows: org.apache.cassandra.serializers.MarshalException: Not
 enough bytes to read 0th field board_id*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
 [apache-cassandra-3.9.jar:3.9]*
 * at
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
 [apache-cassandra-3.9.jar:3.9]*


 I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
 fixes the problem, but then I lose all of my data.

 It looks like its saying there wasn't enough data to read the field
 'board_id', any ideas why that would be?

>>>
>>>
>>
>

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Ali Akhtar]

Any workarounds that don't involve me having to figure out how to uninstall
and re-install a different version?

On Mon, Oct 24, 2016 at 1:24 PM, Ali Akhtar  wrote:

> 3.9..
>
> On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan  wrote:
>
>> Which version of C* ? There was similar issues with commitlogs in tic-toc
>> versions.
>>
>> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:
>>
>>> I have a single node cassandra installation on my dev laptop, which is
>>> used just for dev / testing.
>>>
>>> Recently, whenever I restart my laptop, Cassandra fails to start when I
>>> run it via 'sudo service cassandra start'.
>>>
>>> Doing a tail on /var/log/cassandra/system.log gives this log:
>>>
>>> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
>>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
>>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
>>> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
>>> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
>>> Exiting due to error while processing commit log during initialization.*
>>> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>>> Unexpected error deserializing mutation; saved to
>>> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
>>> mutation against a table with the same name but incompatible schema.
>>> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
>>> enough bytes to read 0th field board_id*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
>>> [apache-cassandra-3.9.jar:3.9]*
>>> * at
>>> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
>>> [apache-cassandra-3.9.jar:3.9]*
>>>
>>>
>>> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
>>> fixes the problem, but then I lose all of my data.
>>>
>>> It looks like its saying there wasn't enough data to read the field
>>> 'board_id', any ideas why that would be?
>>>
>>
>>
>

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[Ali Akhtar]

3.9..

On Mon, Oct 24, 2016 at 1:22 PM, DuyHai Doan  wrote:

> Which version of C* ? There was similar issues with commitlogs in tic-toc
> versions.
>
> On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:
>
>> I have a single node cassandra installation on my dev laptop, which is
>> used just for dev / testing.
>>
>> Recently, whenever I restart my laptop, Cassandra fails to start when I
>> run it via 'sudo service cassandra start'.
>>
>> Doing a tail on /var/log/cassandra/system.log gives this log:
>>
>> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
>> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
>> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
>> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
>> Exiting due to error while processing commit log during initialization.*
>> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>> Unexpected error deserializing mutation; saved to
>> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
>> mutation against a table with the same name but incompatible schema.
>> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
>> enough bytes to read 0th field board_id*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
>> [apache-cassandra-3.9.jar:3.9]*
>> * at
>> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
>> [apache-cassandra-3.9.jar:3.9]*
>>
>>
>> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
>> fixes the problem, but then I lose all of my data.
>>
>> It looks like its saying there wasn't enough data to read the field
>> 'board_id', any ideas why that would be?
>>
>
>

Re: CommitLogReadHandler$CommitLogReadException: Unexpected error deserializing mutation

[DuyHai Doan]

Which version of C* ? There was similar issues with commitlogs in tic-toc
versions.

On Mon, Oct 24, 2016 at 4:18 AM, Ali Akhtar  wrote:

> I have a single node cassandra installation on my dev laptop, which is
> used just for dev / testing.
>
> Recently, whenever I restart my laptop, Cassandra fails to start when I
> run it via 'sudo service cassandra start'.
>
> Doing a tail on /var/log/cassandra/system.log gives this log:
>
> *INFO  [main] 2016-10-24 07:08:02,950 CommitLog.java:166 - Replaying
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676969.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1476907676970.log,
> /var/lib/cassandra/commitlog/CommitLog-6-1477269052845.log*
> *ERROR [main] 2016-10-24 07:08:03,357 JVMStabilityInspector.java:82 -
> Exiting due to error while processing commit log during initialization.*
> *org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation9186356142128811141dat.  This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
> enough bytes to read 0th field board_id*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:410)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:343)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:202)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:85)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:135)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:187)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:167)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:323)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
> [apache-cassandra-3.9.jar:3.9]*
> * at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
> [apache-cassandra-3.9.jar:3.9]*
>
>
> I then have to do 'sudo rm -rf /var/lib/cassandra/commitlog/*' which
> fixes the problem, but then I lose all of my data.
>
> It looks like its saying there wasn't enough data to read the field
> 'board_id', any ideas why that would be?
>

Re: Lightweight transaction inside a batch : request rejected

[DuyHai Doan]

As far as I remember, there is an optimization in Cassandra to manage Paxos
ballot per table. So asking a Paxos operation to span multiple tables (even
if same partition key) would require a lot of changes in the current impl.

The question has already been raised, you may want to convince the
committers by adding some comments here:
https://issues.apache.org/jira/browse/CASSANDRA-10085

On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë 
wrote:

> Hi,
>
> I would like to use lightweight transaction inside a batch but the request
> is rejected by cassandra, however I think this is a use case than could be
> handled without problem.
> Below is what I wanted to do.
>
> I am using cassandra 3.7.
>
> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
>
> CREATE TABLE test_ksp.item (
> user_id bigint,
> item_id text,
> item_value text,
> item_key1 text,
> item_key2 text,
> PRIMARY KEY ((user_id), item_id));
>
> CREATE TABLE test_ksp.item_id_by_key (
> user_id bigint,
> item_key text,
> item_id text,
> PRIMARY KEY ((user_id), item_key));
>
> USE test_ksp;
>
> BEGIN BATCH
> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
> 'key-XYZ-123', 'i11');
> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
> 'key-ABC-789', 'i11');
> APPLY BATCH;
>
>
> So as you can see this is a batch that targets 2 tables but with the same
> partition key (i.e the same target nodes). Moreover It uses only ONE
> condition on one table only.
> I don't understand why cassandra returns an error "Batch with conditions
> cannot span multiple tables" in that case.
>
> I understand that if I had used several conditions on different tables it
> could be a problem, but in my case there is only one condition and moreover
> I have always the same partition key for every table inside the batch.
> As there is only one condition, I expected the paxos protocol just act on
> this condition and as the partition keys are all the same, the paxos
> protocol has only to work with the same replica nodes (not span across
> multiple partition).
> In my point of view this is as if the LWT was in a single statement,
> except that after the LWT is accepted a complete batch has to be executed.
>
> Is there someone that could explain why this use case need to be rejected
> by cassandra? And do you think this is something that cassandra could
> handle in a future version ?
>
> Regards,
> Mickaël
>
>

Lightweight transaction inside a batch : request rejected

[Mickael Delanoë]

Hi,

I would like to use lightweight transaction inside a batch but the request
is rejected by cassandra, however I think this is a use case than could be
handled without problem.
Below is what I wanted to do.

I am using cassandra 3.7.

CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '1'};

CREATE TABLE test_ksp.item (
user_id bigint,
item_id text,
item_value text,
item_key1 text,
item_key2 text,
PRIMARY KEY ((user_id), item_id));

CREATE TABLE test_ksp.item_id_by_key (
user_id bigint,
item_key text,
item_id text,
PRIMARY KEY ((user_id), item_key));

USE test_ksp;

BEGIN BATCH
INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
'key-XYZ-123', 'i11');
INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
'key-ABC-789', 'i11');
APPLY BATCH;


So as you can see this is a batch that targets 2 tables but with the same
partition key (i.e the same target nodes). Moreover It uses only ONE
condition on one table only.
I don't understand why cassandra returns an error "Batch with conditions
cannot span multiple tables" in that case.

I understand that if I had used several conditions on different tables it
could be a problem, but in my case there is only one condition and moreover
I have always the same partition key for every table inside the batch.
As there is only one condition, I expected the paxos protocol just act on
this condition and as the partition keys are all the same, the paxos
protocol has only to work with the same replica nodes (not span across
multiple partition).
In my point of view this is as if the LWT was in a single statement, except
that after the LWT is accepted a complete batch has to be executed.

Is there someone that could explain why this use case need to be rejected
by cassandra? And do you think this is something that cassandra could
handle in a future version ?

Regards,
Mickaël