How to measure the write amplification of C*?

[Dikang Gu]

Hello there,

I'm wondering is there a good way to measure the write amplification of
Cassandra?

I'm thinking it could be calculated by (size of mutations written to the
node)/(number of bytes written to the disk).

Do we already have the metrics of "size of mutations written to the node"?
I did not find it in jmx metrics.

Thanks

-- 
Dikang

Re: Cassandra-stress output

[Stefania Alborghetti]

On Tue, Mar 8, 2016 at 8:39 PM, Jean Carlo 
wrote:

> Hi guys,
>
> I use cassandra stress to populate the next table
>
> CREATE TABLE cf1 (
> kvalue text,
> ktype text,
> prov text,
> dname text,
> dattrib blob,
> dvalue text,
> PRIMARY KEY (kvalue, ktype, prov, dname)
>   ) WITH bloom_filter_fp_chance = 0.01
>  AND caching = '{"keys":"ALL", "rows_per_partition":"60"}'
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.02
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.01
> AND speculative_retry = '99.0PERCENTILE';
>
> And cassandra stress create the next string to the field kvalue of type
> text:
>
> "P*d,xY\x03m\x1b\x10\x0b$\x04pt-G\x08\n`7\x1fs\x15kH\x02i1\x16jf%YM"
>
> what bothers me is that kvalue has control characters like \x03. do you
> guys know any way to avoid creating this kind of characters while using
> cassandra-stress?
>
>
>
> Thank you very much
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>


There is no way to avoid the control characters (<32 and ==127), other than
modifying the source code, which is located in
tools/stress/src/org/apache/cassandra/stress/generate/values/Strings.java.

Changing this line:

chars[i++] = (char) (((v & 127) + 32) & 127);

with this:

chars[i++] = (char) (((v & 127) % 95) + 32);

should work but I could not avoid the expensive modulo operation. You can
rebuild cassandra-stress with ant stress-build.

I wonder if the original intention was to avoid control characters however,
given the +32 in the original line. For this reason I've copied this
message to the dev mailing list.


-- 


[image: datastax_logo.png] 

Stefania Alborghetti

Apache Cassandra Software Engineer

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

Re: Possible bug in Cassandra

[Stefania Alborghetti]

Thank you for reporting this.

I've filed https://issues.apache.org/jira/browse/CASSANDRA-11333.

On Thu, Mar 10, 2016 at 6:16 AM, Rakesh Kumar  wrote:

> Cassandra : 3.3
> CQLSH  : 5.0.1
>
> If there is a typo in the column name of the copy command, we get this:
>
> copy mytable
> (event_id,event_class_cd,event_ts,receive_ts,event_source_instance,client_id,client_id_type,event_tag,event_udf,client_event_date)
> from '/pathtofile.dat'
> with DELIMITER = '|' AND NULL = 'NULL' AND DATETIMEFORMAT='%Y-%m-%d
> %H:%M:%S.%f' ;
>
> Starting copy of mytable with columns ['event_id', 'event_class_cd',
> 'event_ts', 'receive_ts', 'event_source_instance', 'client_id',
> 'client_id_type', 'event_tag', 'event_udf', 'event_client_date'].
>
> load_ravitest.cql:5:13 child process(es) died unexpectedly, aborting
>
> the typo was in the name of event_client_date. It should have been
> client_event_date.
>
>


-- 


[image: datastax_logo.png] 

Stefania Alborghetti

Apache Cassandra Software Engineer

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

Re: How can I make Cassandra stable in a 2GB RAM node environment ?

[Jack Krupansky]

Thanks, Rob, but... I'll continue to do my best to strongly (vehemently, or
is there an even stronger word for me to use?!) discourage use of Cassandra
in under 4/8 GB of memory. Hey, I just want people to be happy, and trying
to run Cassandra in under 8 GB (or 4 GB for dev) is just... asking for
trouble, unhappiness, even despair. Hey, if somebody is smart enough to
figure out how to do it on their own, then great, they are set and don't
need our help, but personally I would declare it as out of bounds/off
limits. But if anybody else here wants to support/encourage it, they are
free to do so and I won't get in their way other than to state my own view.

By "support", I primarily mean what the (open source) code does out of the
box without superhuman effort (BTW, all of the guys at Open Source
Connection ARE superhuman!!) as well as the support of memory of the
community here on this list.

Doc? If anybody thinks there is a better source of doc for open source
Cassandra than the DataStax doc, please point me to it. Until then, I'll
stick with the DataStax doc

That said, it might be interesting to have a no-memory/low-memory mode for
Cassandra which trades off performance for storage capacity. But... that
would be an enhancement, not something that is "supported" out of the box
today. What use cases would this satisfy? I mean, who is it that can get
away with sacrificing performance these days?

-- Jack Krupansky

On Mon, Mar 7, 2016 at 3:29 PM, Ben Bromhead  wrote:

> +1 for
> http://opensourceconnections.com/blog/2013/08/31/building-
> the-perfect-cassandra-test-environment/
> 
>
>
> We also run Cassandra on t2.mediums for our Developer clusters. You can
> force Cassandra to do most "memory" things by hitting the disk instead (on
> disk compaction passes, flush immediately to disk) and by throttling client
> connections. In fact on the t2 series memory is not the biggest concern,
> but rather the CPU credit issue.
>
> On Mon, 7 Mar 2016 at 11:53 Robert Coli  wrote:
>
>> On Fri, Mar 4, 2016 at 8:27 PM, Jack Krupansky 
>> wrote:
>>
>>> Please review the minimum hardware requirements as clearly documented:
>>>
>>> http://docs.datastax.com/en/cassandra/3.x/cassandra/planning/planPlanningHardware.html
>>>
>>
>> That is a document for Datastax Cassandra, not Apache Cassandra. It's
>> wonderful that Datastax provides docs, but Datastax Cassandra is a superset
>> of Apache Cassandra. Presuming that the requirements of one are exactly
>> equivalent to the requirements of the other is not necessarily reasonable.
>>
>> Please adjust your hardware usage to at least meet the clearly documented
>>> minimum requirements. If you continue to encounter problems once you have
>>> corrected your configuration error, please resubmit the details with
>>> updated hardware configuration details.
>>>
>>
>> Disagree. OP specifically stated that they knew this was not a
>> recommended practice. It does not seem unlikely that they are constrained
>> to use this hardware for reasons outside of their control.
>>
>>
>>> Just to be clear, development on less than 4 GB is not supported and
>>> production on less than 8 GB is not supported. Those are not suggestions or
>>> guidelines or recommendations, they are absolute requirements.
>>>
>>
>> What does "supported" mean here? That Datastax will not provide support
>> if you do not follow the above recommendations? Because it certainly is
>> "supported" in the sense of "it can be made to work" ... ?
>>
>> The premise of a minimum RAM level seems meaningless without context. How
>> much data are you serving from your 2GB RAM node? What is the rate of
>> client requests?
>>
>> To be clear, I don't recommend trying to run production Cassandra with
>> under 8GB of RAM on your node, but "absolute requirement" is a serious
>> overstatement.
>>
>>
>> http://opensourceconnections.com/blog/2013/08/31/building-the-perfect-cassandra-test-environment/
>>
>> Has some good discussion of how to run Cassandra in a low memory
>> environment. Maybe someone should tell John that his 64MB of JVM heap for a
>> test node is 62x too small to be "supported"? :D
>>
>> =Rob
>>
>> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>

Possible bug in Cassandra

[Rakesh Kumar]

Cassandra : 3.3
CQLSH  : 5.0.1

If there is a typo in the column name of the copy command, we get this:


copy mytable 
(event_id,event_class_cd,event_ts,receive_ts,event_source_instance,client_id,client_id_type,event_tag,event_udf,client_event_date)
from '/pathtofile.dat'
with DELIMITER = '|' AND NULL = 'NULL' AND DATETIMEFORMAT='%Y-%m-%d 
%H:%M:%S.%f' ;



Starting copy of mytable with columns ['event_id', 'event_class_cd', 
'event_ts', 'receive_ts', 'event_source_instance', 'client_id', 
'client_id_type', 'event_tag', 'event_udf', 'event_client_date'].
  
load_ravitest.cql:5:13 child process(es) died unexpectedly, aborting



the typo was in the name of event_client_date. It should have been 
client_event_date.

Re: Unexplainably large reported partition sizes

[Robert Coli]

On Mon, Mar 7, 2016 at 1:25 PM, Nate McCall  wrote:

>
>> Rob, can you remember which bug/jira this was? I have not been able to
>> find it.
>> I'm using 2.1.9.
>>
>
> https://issues.apache.org/jira/browse/CASSANDRA-7953
>
> Rob may have a different one, but I've something similar from this issue.
> Fixed in 2.1.12.
>

Nate is correct, I was referring to CASSANDRA-7953... :)

=Rob

Re: Exception about too long clustering key

[Emīls Šolmanis]

Hey Alex,

I did do a grep for that message in the driver code base and it seems like
it's not there, so I think this is coming from the server.

Only thing I can think of is us exceeding one of the limits (e.g., the 65K
collection item one) and then the error message being super misleading.
I'll check the server code tomorrow and see if I can track that message
down.

Regards,
Emils

On Wed, 9 Mar 2016 20:02 Alex Popescu,  wrote:

> Hi Emīls,
>
> Directing this question to the Java driver mailing list will give you
> better chances to get an answer:
> https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user
>
> (as a side note, I haven't seen this one before)
>
> On Wed, Mar 9, 2016 at 11:52 AM, Emīls Šolmanis 
> wrote:
>
>> Hello,
>>
>> I keep getting an exception about a clustering key being too long, like
>>
>> com.datastax.driver.core.exceptions.InvalidQueryException: The sum of all 
>> clustering columns is too long (72650 > 65535)
>>  at 
>> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
>>  at 
>> com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:179)
>>  at 
>> com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:184)
>>
>>
>> But the table has no clustering key. Even if I set the clustering key to
>> a single column that's guaranteed to be a string around 4-5 characters, I
>> get the same thing.
>>
>> The only result Google gave me suggested this was about the clustering
>> key names, so I renamed all the fields in the schema def to 1-3 letters, to
>> no avail.
>>
>> Does anyone know what this is about and how I can solve this?
>>
>> Running Cassandra 2.2.4, Datastax driver 3.0.0.
>>
>> Regards,
>> Emils
>>
>
>
>
> --
> Bests,
>
> Alex Popescu | @al3xandru
> Sen. Product Manager @ DataStax
>
>

Re: Exception about too long clustering key

[Alex Popescu]

Hi Emīls,

Directing this question to the Java driver mailing list will give you
better chances to get an answer:
https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user

(as a side note, I haven't seen this one before)

On Wed, Mar 9, 2016 at 11:52 AM, Emīls Šolmanis 
wrote:

> Hello,
>
> I keep getting an exception about a clustering key being too long, like
>
> com.datastax.driver.core.exceptions.InvalidQueryException: The sum of all 
> clustering columns is too long (72650 > 65535)
>   at 
> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
>   at 
> com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:179)
>   at 
> com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:184)
>
>
> But the table has no clustering key. Even if I set the clustering key to a
> single column that's guaranteed to be a string around 4-5 characters, I get
> the same thing.
>
> The only result Google gave me suggested this was about the clustering key
> names, so I renamed all the fields in the schema def to 1-3 letters, to no
> avail.
>
> Does anyone know what this is about and how I can solve this?
>
> Running Cassandra 2.2.4, Datastax driver 3.0.0.
>
> Regards,
> Emils
>



-- 
Bests,

Alex Popescu | @al3xandru
Sen. Product Manager @ DataStax

Exception about too long clustering key

[Emīls Šolmanis]

Hello,

I keep getting an exception about a clustering key being too long, like

com.datastax.driver.core.exceptions.InvalidQueryException: The sum of
all clustering columns is too long (72650 > 65535)
at 
com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
at 
com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:179)
at 
com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:184)


But the table has no clustering key. Even if I set the clustering key to a
single column that's guaranteed to be a string around 4-5 characters, I get
the same thing.

The only result Google gave me suggested this was about the clustering key
names, so I renamed all the fields in the schema def to 1-3 letters, to no
avail.

Does anyone know what this is about and how I can solve this?

Running Cassandra 2.2.4, Datastax driver 3.0.0.

Regards,
Emils

Re: nulls in prepared statement & tombstones?

[Steve Robenalt]

Thanks Adam, that's good to know.

On Wed, Mar 9, 2016 at 7:42 AM, Adam Holmberg 
wrote:

> The referenced article is accurate as far as NULL is concerned, but please
> also note that there is now the ability to specify UNSET to avoid
> unnecessary tombstones (as of Cassandra 2.2.0):
> https://issues.apache.org/jira/browse/CASSANDRA-7304
>
> Adam
>
> On Tue, Mar 8, 2016 at 12:15 PM, Henry M  wrote:
>
>> Thank you. It's probably not specific to prepared statements then and
>> just a more general statement. That makes sense.
>>
>>
>> On Tue, Mar 8, 2016 at 10:06 AM Steve Robenalt 
>> wrote:
>>
>>> Hi Henry,
>>>
>>> I would suspect that the tombstones are necessary to overwrite any
>>> previous values in the null'd columns. Since Cassandra avoids
>>> read-before-write, there's no way to be sure that the nulls were not
>>> intended to remove any such previous values, so the tombstones insure that
>>> they don't re-appear.
>>>
>>> Steve
>>>
>>>
>>>
>>> On Tue, Mar 8, 2016 at 9:36 AM, Henry Manasseh 
>>> wrote:
>>>
 The following article makes the following statement which I am trying
 to understand:

 *"Cassandra’s storage engine is optimized to avoid storing unnecessary
 empty columns, but when using prepared statements those parameters that are
 not provided result in null values being passed to Cassandra (and thus
 tombstones being stored)." *
 http://www.datastax.com/dev/blog/4-simple-rules-when-using-the-datastax-drivers-for-cassandra

 I was wondering if someone could help explain why sending nulls as part
 of a prepared statement update would result in tombstones.

 Thank you,
 - Henry

>>>
>>>
>>>
>>> --
>>> Steve Robenalt
>>> Software Architect
>>> sroben...@highwire.org 
>>> (office/cell): 916-505-1785
>>>
>>> HighWire Press, Inc.
>>> 425 Broadway St, Redwood City, CA 94063
>>> www.highwire.org
>>>
>>> Technology for Scholarly Communication
>>>
>>
>


-- 
Steve Robenalt
Software Architect
sroben...@highwire.org 
(office/cell): 916-505-1785

HighWire Press, Inc.
425 Broadway St, Redwood City, CA 94063
www.highwire.org

Technology for Scholarly Communication

Re: ntpd clock sync

[K F]

the clock is about 30 to 40 seconds behind.

  From: Jack Krupansky 
 To: user@cassandra.apache.org 
 Sent: Wednesday, March 9, 2016 11:31 AM
 Subject: Re: ntpd clock sync
   
How far out of sync are the nodes? A few minutes or less? Many hours?
Worst case, you could simply take the entire cluster down until that future 
time has passed and then bring it back up.

-- Jack Krupansky
On Wed, Mar 9, 2016 at 11:27 AM, Jeff Jirsa  wrote:

If you don’t overwrite or delete data, it’s not a concern.If the clocks show a 
time in the past instead of in the future, it’s not a concern.
If the clock has drifted significantly into the future, when you start NTP you 
may be writing data with timestamps lower than timestamps on data that already 
exists. In this case, the existing data (with timestamps in the future) may 
take precedence over new writes (with correct timestamps).


From:  K F
Reply-To:  "user@cassandra.apache.org", K F
Date:  Wednesday, March 9, 2016 at 8:23 AM
To:  User
Subject:  ntpd clock sync

Hi,
I have question about ntpd. In certain clusters where new datacenters were 
added since 1 week we stood-up those machines didn't have ntpd running on them. 
Will it cause any problem if we enable or start ntpd now on those newly added 
datacenters. 
Thanks.



  

Re: Automatically connect to any up node via cqlsh

[Tyler Hobbs]

On Wed, Mar 9, 2016 at 8:09 AM, Rakesh Kumar  wrote:

>
> Is it possible to set up cassandra/cqlsh so that if any node is down,
> cqlsh will automatically try to connect to the other surviving nodes,
> instead of erroring out. I know it is possible to supply ip_address and
> port of the UP node as arguments to cqlsh, but I am looking at automatic
> detection.
>

No, right now cqlsh is designed to connect to only a single node.


-- 
Tyler Hobbs
DataStax 

Re: ntpd clock sync

[Jack Krupansky]

How far out of sync are the nodes? A few minutes or less? Many hours?

Worst case, you could simply take the entire cluster down until that future
time has passed and then bring it back up.


-- Jack Krupansky

On Wed, Mar 9, 2016 at 11:27 AM, Jeff Jirsa 
wrote:

> If you don’t overwrite or delete data, it’s not a concern.
> If the clocks show a time in the past instead of in the future, it’s not a
> concern.
>
> If the clock has drifted significantly into the future, when you start NTP
> you may be writing data with timestamps lower than timestamps on data that
> already exists. In this case, the existing data (with timestamps in the
> future) may take precedence over new writes (with correct timestamps).
>
>
>
> From: K F
> Reply-To: "user@cassandra.apache.org", K F
> Date: Wednesday, March 9, 2016 at 8:23 AM
> To: User
> Subject: ntpd clock sync
>
> Hi,
>
> I have question about ntpd. In certain clusters where new datacenters were
> added since 1 week we stood-up those machines didn't have ntpd running on
> them. Will it cause any problem if we enable or start ntpd now on those
> newly added datacenters.
>
> Thanks.
>

Re: ntpd clock sync

[Jeff Jirsa]

If you don’t overwrite or delete data, it’s not a concern.
If the clocks show a time in the past instead of in the future, it’s not a 
concern.

If the clock has drifted significantly into the future, when you start NTP you 
may be writing data with timestamps lower than timestamps on data that already 
exists. In this case, the existing data (with timestamps in the future) may 
take precedence over new writes (with correct timestamps).



From:  K F
Reply-To:  "user@cassandra.apache.org", K F
Date:  Wednesday, March 9, 2016 at 8:23 AM
To:  User
Subject:  ntpd clock sync

Hi,

I have question about ntpd. In certain clusters where new datacenters were 
added since 1 week we stood-up those machines didn't have ntpd running on them. 
Will it cause any problem if we enable or start ntpd now on those newly added 
datacenters. 

Thanks.



smime.p7s
Description: S/MIME cryptographic signature

ntpd clock sync

[K F]

Hi,
I have question about ntpd. In certain clusters where new datacenters were 
added since 1 week we stood-up those machines didn't have ntpd running on them. 
Will it cause any problem if we enable or start ntpd now on those newly added 
datacenters. 
Thanks.

Re: [C*2.1]memtable_allocation_type: offheap_objects

[Jeff Jirsa]

We use them. No signs of stability problems in 2.1 that we’ve attributed to 
offheap objects.


From:  "aeljami@orange.com"
Reply-To:  "user@cassandra.apache.org"
Date:  Wednesday, March 9, 2016 at 1:54 AM
To:  user
Subject:  [C*2.1]memtable_allocation_type: offheap_objects

Hi,

 

offheap_objects was removed in releases 3.2.x then reintroduced  in release 
3.4: I vould like to know if someone has used offheap_objects in Cassandra 2.1: 
stable or not, improvementobservedor not…

 

Thanks.

Ahmed

 
_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



smime.p7s
Description: S/MIME cryptographic signature

Re: [C*2.1]memtable_allocation_type: offheap_objects

[Jonathan Haddad]

Check out Al's Tuning Guide.  He discusses offheap objects.

https://tobert.github.io/pages/als-cassandra-21-tuning-guide.html

On Wed, Mar 9, 2016 at 1:54 AM  wrote:

> Hi,
>
>
>
> offheap_objects was removed in releases 3.2.x then reintroduced  in
> release 3.4: I vould like to know if someone has used offheap_objects in
> Cassandra 2.1: stable or not, improvement observed or not…
>
>
>
> Thanks.
>
> Ahmed
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>

Re: nulls in prepared statement & tombstones?

[Adam Holmberg]

The referenced article is accurate as far as NULL is concerned, but please
also note that there is now the ability to specify UNSET to avoid
unnecessary tombstones (as of Cassandra 2.2.0):
https://issues.apache.org/jira/browse/CASSANDRA-7304

Adam

On Tue, Mar 8, 2016 at 12:15 PM, Henry M  wrote:

> Thank you. It's probably not specific to prepared statements then and just
> a more general statement. That makes sense.
>
>
> On Tue, Mar 8, 2016 at 10:06 AM Steve Robenalt 
> wrote:
>
>> Hi Henry,
>>
>> I would suspect that the tombstones are necessary to overwrite any
>> previous values in the null'd columns. Since Cassandra avoids
>> read-before-write, there's no way to be sure that the nulls were not
>> intended to remove any such previous values, so the tombstones insure that
>> they don't re-appear.
>>
>> Steve
>>
>>
>>
>> On Tue, Mar 8, 2016 at 9:36 AM, Henry Manasseh 
>> wrote:
>>
>>> The following article makes the following statement which I am trying to
>>> understand:
>>>
>>> *"Cassandra’s storage engine is optimized to avoid storing unnecessary
>>> empty columns, but when using prepared statements those parameters that are
>>> not provided result in null values being passed to Cassandra (and thus
>>> tombstones being stored)." *
>>> http://www.datastax.com/dev/blog/4-simple-rules-when-using-the-datastax-drivers-for-cassandra
>>>
>>> I was wondering if someone could help explain why sending nulls as part
>>> of a prepared statement update would result in tombstones.
>>>
>>> Thank you,
>>> - Henry
>>>
>>
>>
>>
>> --
>> Steve Robenalt
>> Software Architect
>> sroben...@highwire.org 
>> (office/cell): 916-505-1785
>>
>> HighWire Press, Inc.
>> 425 Broadway St, Redwood City, CA 94063
>> www.highwire.org
>>
>> Technology for Scholarly Communication
>>
>

Automatically connect to any up node via cqlsh

[Rakesh Kumar]

Cassandra : 3.3
CQLSH  : 5.0.1


Is it possible to set up cassandra/cqlsh so that if any node is down, cqlsh 
will automatically try to connect to the other surviving nodes, instead of 
erroring out. I know it is possible to supply ip_address and port of the UP 
node as arguments to cqlsh, but I am looking at automatic detection.


thanks

Re: moving keyspaces to another disk while Cassandra is running

[Krzysztof Księżyk]

Robert Coli  eventbrite.com> writes:

> 
> On Mon, Mar 7, 2016 at 2:57 AM, Krzysztof Księżyk  
gmail.com> wrote:I see on lsof output that even if keyspace
> is not queried, Cassandra keeps files opened, so I guess it's not safe to
> hotswap, but I'd like to make sure.
> 
> 
> It is not safe for exactly this reason. Just restart your nodes.
> 
> Were I doing this process, I would :
> 
> 1) do initial rsync
> 2) stop node
> 3) do rsync again, with --delete for files which are no longer in the 
source. This is very important, or you risk resurrecting SSTables which 
have already been compacted away, which can be PERMANENTLY FATAL TO THE 
CONSISTENCY OF ALL INVOLVED DATA.
> 4) start node
> 
> =Rob
> 
> 

Hi,

Thanks for answer. I do it exactly this way.

Kind regards -
Krzysztof Ksiezyk

Re: moving keyspaces to another disk while Cassandra is running

[Krzysztof Księżyk]

Jack Krupansky  gmail.com> writes:

> 
> 
> If your data is replicated properly (RF=3) and you do QUORUM reads and 
writes, you should be able to shut down one node, adjust the configuration, 
and restart that node and all should be fine. Do it quickly enough (less 
than an hour) and the node should quickly catch up with any changes.
> How small is small? Six nodes?
> 
> 
> -- Jack Krupansky
> On Mon, Mar 7, 2016 at 5:57 AM, Krzysztof Księżyk  
gmail.com> wrote:Hi,
> I have small Cassandra cluster running on boxes with 256GB SSD and 2TB 
HDD.
> Originally SSD was for system and commit log and HDD for data. But
> unfortunately because of nature of queries, performance was not 
satisfactory
> and to improve it, data were moved to SSD as well. Now problem is with 
SSD
> size being too small to keep all data. As there's one keyspace created a
> month, my idea was to move historical keyspaces to HDD and make a 
symlink.
> These historical keyspaces are not queried often so it shouldn't affect
> performance much. I've written simple script that rsyncs data, stops
> Cassandra, makes symlink and starts Cassandra node again, but I have 
question
> if there will be problem if I make hotswap - without stopping Cassandra
> daemon. So... rsync, rename current keyspace folder in data dir, make 
symlink
> to new location on HDD. One good thing is that while keyspace is fully 
feed
> with data, it no longer changes. I see on lsof output that even if 
keyspace
> is not queried, Cassandra keeps files opened, so I guess it's not safe to
> hotswap, but I'd like to make sure.
> Kind regards -
> Krzysztof Ksiezyk
> 
> 
> 
> 
> 


Hi,

Thank you for answer. Small cluster - 4 boxes. Data has RF=2 and worker 
uses 
read-consistency-level = ONE. Good thing is that data is immutable in 
keyspace after initial load, but problem is that worker querying Cassandra 
(using Titan) dies when node it uses, is down, even for a short period. 
Seems it's by bad design of worker but I can't fix it easily now, so 
initial idea was to preserve Cassandra online whole the time.

Kind regards -
Krzysztof Ksiezyk

[C*2.1]memtable_allocation_type: offheap_objects

[aeljami.ext]

Hi,

offheap_objects was removed in releases 3.2.x then reintroduced  in release 
3.4: I vould like to know if someone has used offheap_objects in Cassandra 2.1: 
stable or not, improvement observed or not...

Thanks.
Ahmed


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.