Re: Introducing Cassandra 3.7 LTS

[Jason J. W. Williams]

+1

On Wed, Oct 19, 2016 at 2:07 PM, sfesc...@gmail.com 
wrote:

> Wow, thank you for doing this. This sentiment regarding stability seems to
> be widespread. Is the team reconsidering the whole tick-tock cadence? If
> not, I would add my voice to those asking that it is revisited.
>
> Steve
>
> On Wed, Oct 19, 2016 at 1:00 PM Matija Gobec  wrote:
>
>> Hi Ben,
>>
>> Thanks for this awesome contribution. I'm eager to give it a try and test
>> it out.
>>
>> Best,
>> Matija
>>
>> On Wed, Oct 19, 2016 at 8:55 PM, Ben Bromhead 
>> wrote:
>>
>> Hi All
>>
>> I am proud to announce we are making available our production build of
>> Cassandra 3.7 that we run at Instaclustr (both for ourselves and our
>> customers). Our release of Cassandra 3.7 includes a number of backported
>> patches from later versions of Cassandra e.g. 3.8 and 3.9 but doesn't
>> include the new features of these releases.
>>
>> You can find our release of Cassandra 3.7 LTS on github here (
>> https://github.com/instaclustr/cassandra). You can read more of our
>> thinking and how this applies to our managed service here (
>> https://www.instaclustr.com/blog/2016/10/19/patched-cassandra-3-7/).
>>
>> We also have an expanded FAQ about why and how we are approaching 3.x in
>> this manner (https://github.com/instaclustr/cassandra#cassandra-37-lts),
>> however I've included the top few question and answers below:
>>
>> *Is this a fork?*
>> No, This is just Cassandra with a different release cadence for those who
>> want 3.x features but are slightly more risk averse than the current
>> schedule allows.
>>
>> *Why not just use the official release?*
>> With the 3.x tick-tock branch we have encountered more instability than
>> with the previous release cadence. We feel that releasing new features
>> every other release makes it very hard for operators to stabilize their
>> production environment without bringing in brand new features that are not
>> battle tested. With the release of Cassandra 3.8 and 3.9 simultaneously the
>> bug fix branch included new and real-world untested features, specifically
>> CDC. We have decided to stick with Cassandra 3.7 and instead backport
>> critical issues and maintain it ourselves rather than trying to stick with
>> the current Apache Cassandra release cadence.
>>
>> *Why backport?*
>> At Instaclustr we support and run a number of different versions of
>> Apache Cassandra on behalf of our customers. Over the course of managing
>> Cassandra for our customers we often encounter bugs. There are existing
>> patches for some of them, others we patch ourselves. Generally, if we can,
>> we try to wait for the next official Apache Cassandra release, however in
>> the need to ensure our customers remain stable and running we will
>> sometimes backport bugs and write our own hotfixes (which are also
>> submitted back to the community).
>>
>> *Why release it?*
>> A number of our customers and people in the community have asked if we
>> would make this available, which we are more than happy to do so. This
>> repository represents what Instaclustr runs in production for Cassandra 3.7
>> and this is our way of helping the community get a similar level of
>> stability as what you would get from our managed service.
>>
>> Cheers
>>
>> Ben
>>
>>
>>
>> --
>> Ben Bromhead
>> CTO | Instaclustr 
>> +1 650 284 9692
>> Managed Cassandra / Spark on AWS, Azure and Softlayer
>>
>>
>>

Re: Adding Materialized View triggers "Mutation Too Large" error.

[Jason J. W. Williams]

Hi Paulo,

Thanks for bug link! I've subscribed to it for updates. Thankfully, these
tables for something still in beta so we can wipe the data. But it'll be
great when its fixed.

-J

On Mon, Aug 8, 2016 at 4:26 PM, Paulo Motta <pauloricard...@gmail.com>
wrote:

> What happens is that when trying to rebuild the MV, the rebuilder tries to
> create a very large batch that exceeds commitlog_segment_size_in_mb. This
> limitation is currently being addressed on CASSANDRA-11670. Two options I
> can see to workaround this for now:
> 1) increase commitlog_segment_size_in_mb as you suggested
> 2) Re-create the base table and views and reinsert all data again to the
> base able.
>
> 2016-08-08 19:52 GMT-03:00 Jason J. W. Williams <jasonjwwilli...@gmail.com
> >:
>
>> HI Guys,
>>
>> We're running Cassandra 3.0.8, and needed to add a field to a table and
>> it's materialized views. We dropped the MVs, added the fields to the
>> underlying table, and recreated MVs with the new fields. However, the MV
>> creation is failing with:
>>
>>
>> WARN  [CompactionExecutor:6933] 2016-08-08 22:48:11,075
>> ViewBuilder.java:178 - Materialized View failed to complete, sleeping 5
>> minutes before restarting
>> java.lang.IllegalArgumentException: Mutation of 17709054 bytes is too
>> large for the maximum size of 16777216
>>
>> https://gist.github.com/williamsjj/49e4c6a0b3324343205386d040560e1e
>>
>> I'm considering bumping commitlog_segment_size_in_mb up to 64MB to get
>> around this, but it seems like the MV code should be smart enough to stay
>> under the limit.
>>
>> Any advice is greatly appreciated.
>>
>> -J
>>
>
>

Adding Materialized View triggers "Mutation Too Large" error.

[Jason J. W. Williams]

HI Guys,

We're running Cassandra 3.0.8, and needed to add a field to a table and
it's materialized views. We dropped the MVs, added the fields to the
underlying table, and recreated MVs with the new fields. However, the MV
creation is failing with:


WARN  [CompactionExecutor:6933] 2016-08-08 22:48:11,075
ViewBuilder.java:178 - Materialized View failed to complete, sleeping 5
minutes before restarting
java.lang.IllegalArgumentException: Mutation of 17709054 bytes is too large
for the maximum size of 16777216

https://gist.github.com/williamsjj/49e4c6a0b3324343205386d040560e1e

I'm considering bumping commitlog_segment_size_in_mb up to 64MB to get
around this, but it seems like the MV code should be smart enough to stay
under the limit.

Any advice is greatly appreciated.

-J

Re: DTCS SSTable count issue

[Jason J. W. Williams]

I can vouch for TWCS...we switched from DTCS to TWCS using Jeff's plugin w/
Cassandra 3.0.5 and just upgraded to 3.0.8 today and switched over to the
built-in version of TWCS.

-J

On Mon, Jul 11, 2016 at 1:38 PM, Jeff Jirsa 
wrote:

> DTCS is deprecated in favor of TWCS in new versions, yes.
>
>
>
> Worth mentioning that you can NOT disable blocking read repair which comes
> naturally if you use CL > ONE.
>
>
>
> >  Also instead of major compactions (which comes with its set of issues
> / tradeoffs too) you can think of a script smartly using sstablemetadata to
> find the sstables holding too much tombstones and running single SSTable
> compactions on them through JMX and user defined compactions. Meanwhile if
> you want to do it manually, you could do it with something like this to
> know the tombstone ratio from the biggest sstable:
>
>
>
> The tombstone compaction options basically do this for you for the right
> settings (unchecked tombstone compaction = true, set threshold to 85% or
> so, don’t try to get clever and set it to something very close to 99%, the
> estimated tombstone ratio isn’t that accurate)
>
>
>
> -  Jeff
>
>
>
>
>
> *From: *Alain RODRIGUEZ 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Monday, July 11, 2016 at 1:05 PM
> *To: *"user@cassandra.apache.org" 
> *Subject: *Re: DTCS SSTable count issue
>
>
>
> @Jeff
>
>
>
> Rather than being an alternative, isn't your compaction strategy going to
> deprecate (and finally replace) DTCS ? That was my understanding from the
> ticket CASSANDRA-9666.
>
> @Riccardo
>
>
>
> If you are interested in TWCS from Jeff, I believe it has been introduced
> in 3.0.8 actually, not 3.0.7
> https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt#L28
> .
> Anyway, you can use it in any recent version as compactions strategies are
> pluggable.
>
>
>
> What concerns me is that I have an high tombstone read count despite those
> are insert only tables. Compacting the table make the tombstone issue
> disappear. Yes, we are using TTL to expire data after 3 months and I have
> not touch the GC grace period.
>
>
>
> I observed the same issue recently and I am confident that TWCS will solve
> this tombstone issue, but it is not tested on my side so far. Meanwhile, be
> sure you have disabled any "read repair" on tables using DTCS and maybe
> hints as well. It is a hard decision to take as you'll loose 2 out of 3
> anti entropy systems, but DTCS behaves badly with those options turned on
> (TWCS is fine with it). The last anti-entropy being a full repair that you
> might already not be running as you only do inserts...
>
>
>
> Also instead of major compactions (which comes with its set of issues /
> tradeoffs too) you can think of a script smartly using sstablemetadata to
> find the sstables holding too much tombstones and running single SSTable
> compactions on them through JMX and user defined compactions. Meanwhile if
> you want to do it manually, you could do it with something like this to
> know the tombstone ratio from the biggest sstable:
>
> du -sh /path_to_a_table/* | sort -h | tail -20 | awk "{print $1}" && du
> -sh /path_to_a_table/* | sort -h | tail -20 | awk "{print $2}" | xargs
> sstablemetadata | grep tombstones
>
> And something like this to run a user defined compaction on the ones you
> chose (big sstable with high tombstone ratio):
>
> echo "run -b org.apache.cassandra.db:type=CompactionManager
> forceUserDefinedCompaction " | java -jar
> jmxterm-version.jar -l :
>
> *note:* you have to download jmxterm (or use any other jmx tool).
>
>
>
> Did you give a try to the unchecked_tombstone_compaction as well
> (compaction options at the table level)? Feel free to set this one to true.
> I think it could be the default. It is safe as long as your machines have
> some more resources available (not that much). That's the first thing I
> would do.
>
>
>
> Also if you use TTL only, feel free to reduce the gc_grace_seconds, this
> will probably help having tombstones removed. I would start with other
> solutions first. Keep in mind that if someday you perform deletes, this
> setting could produce you some Zombies (data coming back), if you don't run
> repair in the gc_grace_seconds for the entire ring.
>
> C*heers,
>
> ---
>
> Alain Rodriguez - al...@thelastpickle.com
>
> France
>
>
>
> The Last Pickle - Apache Cassandra Consulting
>
> http://www.thelastpickle.com
> 

Adding column to materialized view

[Jason J. W. Williams]

Hey Guys,

Running Cassandra 3.0.5. Needed to add a column to a materialized view, but
ALTER MATERIALIZED VIEW doesn't seem to allow that. So we ended up dropping
the view and recreating it. Is that expected or did I miss something in the
docs?

-J

Re: Understanding when Cassandra drops expired time series data

[Jason J. W. Williams]

Hey Jeff,

Do most of those behaviors apply to TWCS too?

-J

On Fri, Jun 17, 2016 at 1:25 PM, Jeff Jirsa 
wrote:

> First, DTCS in 2.0.15 has some weird behaviors -
> https://issues.apache.org/jira/browse/CASSANDRA-9572 .
>
>
>
> That said, some other general notes:
>
>
> Data deleted by TTL isn’t the same as issuing a delete – each expiring
> cell internally has a ttl/timestamp at which it will be converted into a
> tombstone. There is no tombstone added to the memtable, or flushed to disk
> – it just treats the expired cells as tombstones once they’re past that
> timestamp.
>
>
>
>
> Cassandra’s getFullyExpiredSSTables() will consider a table fully expired
> if (and only if) all cells within that table are expired (current time >
> max timestamp ) AND the sstable timestamps don’t overlap with others that
> aren’t fully expired. Björn talks about this in
> https://issues.apache.org/jira/browse/CASSANDRA-8243 - the intent here is
> so that explicit deletes (which do create tombstones) won’t be GC’d  from
> an otherwise fully expired sstable if they’re covering data in a more
> recent sstable – without this check, we could accidentally bring dead data
> back to life. In an append only time series workload this would be unusual,
> but not impossible.
>
> Unfortunately, read repairs (foreground/blocking, if you write with CL <
> ALL and read with CL > ONE) will cause cells written with old timestamps to
> be written into the newly flushed sstables, which creates sstables with
> wide gaps between minTimestamp and maxTimestamp (you could have a read
> repair pull data that is 23 hours old into a new sstable, and now that one
> sstable spans 23 hours, and isn’t fully expired until the oldest data is 47
> hours old). There’s an open ticket (
> https://issues.apache.org/jira/browse/CASSANDRA-10496 ) meant to make
> this behavior ‘better’ in the future by splitting those old read-repaired
> cells from the newly flushed sstables.
>
>
>
>
> I gave a talk on a lot of this behavior last year at Summit (
> http://www.slideshare.net/JeffJirsa1/cassandra-summit-2015-real-world-dtcs-for-operators
> ) - if you’re running time series in production on DTCS, it’s worth a
> glance.
>
>
>
>
>
>
>
> *From: *jerome 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Friday, June 17, 2016 at 11:52 AM
> *To: *"user@cassandra.apache.org" 
> *Subject: *Understanding when Cassandra drops expired time series data
>
>
>
> Hello! Recently I have been trying to familiarize myself with Cassandra
> but don't quite understand when data is removed from disk after it has been
> deleted. The use case I'm particularly interested is expiring time series
> data with DTCS. As an example, I created the following table:
>
> CREATE TABLE metrics (
>
>   metric_id text,
>
>   time timestamp,
>
>   value double,
>
>   PRIMARY KEY (metric_id, time),
>
> ) WITH CLUSTERING ORDER BY (time DESC) AND
>
>  default_time_to_live = 86400 AND
>
>  gc_grace_seconds = 3600 AND
>
>  compaction = {
>
>   'class': 'DateTieredCompactionStrategy',
>
>   'timestamp_resolution':'MICROSECONDS',
>
>   'base_time_seconds':'3600',
>
>   'max_sstable_age_days':'365',
>
>   'min_threshold':'4'
>
>  };
>
> I understand that Cassandra will create a tombstone for all rows inserted
> into this table 24 hours after they are inserted (86400 seconds). These
> tombstones will first be written to an in-memory Memtable and then flushed
> to disk as an SSTable when the Memtable reaches a certain size. My question
> is when will the data that is now expired be removed from disk? Is it the
> next time the SSTable which contains the data gets compacted? So, with DTCS
> and min_threshold set to four, we would wait until at least three other
> SSTables are in the same time window as the expired data, and then those
> SSTables will be compacted into a SSTable without the expired data. Is it
> only during this compaction that the data will be removed? It seems to me
> that this would require Cassandra to maintain some metadata on which rows
> have been deleted since the newer tombstones would likely not be in the
> older SSTables that are being compacted. Also, I'm aware that Cassandra can
> drop entire SSTables if they contain only expired data but I'm unsure of
> what qualifies as expired data (is it just SSTables whose maximum
> timestamp is past the default TTL for the table?) and when such SSTables
> are dropped.
>
> Alternatively, do the SSTables which contain the tombstones have to be
> compacted with the SSTables which contain the expired data for the data to
> be removed? It seems to me that this could result in Cassandra holding the
> expired data long after it has expired since it's waiting for the new
> tombstones to be compacted with the older expired data.
>
> Finally, I was also unsure when the tombstones themselves are removed. I
> 

Re: Multi-DC Cluster w/ non-replicated Keyspace

[Jason J. W. Williams]

It was my mistake. Before I checked the trace I assume it meant the data
also had been replicated to the remote cluster, which is why it could
answer the request. Thank you for responding so quickly and helping correct
my misunderstanding. As long as the data isn't being replicated, everything
else is fine.

-J

On Thu, Jun 16, 2016 at 8:05 PM, Ben Slater <ben.sla...@instaclustr.com>
wrote:

> That’s the behaviour I would have expected. I’m not aware of anyway to
> prevent this and would be surprised if there is one (but I’ve never tried
> to find one either so it might be possible).
>
> Cheers
> Ben
>
> On Fri, 17 Jun 2016 at 12:02 Jason J. W. Williams <
> jasonjwwilli...@gmail.com> wrote:
>
>> Hey Ben,
>>
>> Looks like just the schema. I was surprised that running SELECTs against
>> the DC which should not have any data (because it's not specified in
>> NetworkTopologyStrategy), actually returned data. But looking at the query
>> trace it looks like its forwarding the queries to the other DC.
>>
>> -J
>>
>> On Thu, Jun 16, 2016 at 7:55 PM, Ben Slater <ben.sla...@instaclustr.com>
>> wrote:
>>
>>> Do you mean the data is getting replicated or just the schema?
>>>
>>> On Fri, 17 Jun 2016 at 11:48 Jason J. W. Williams <
>>> jasonjwwilli...@gmail.com> wrote:
>>>
>>>> Hi Guys,
>>>>
>>>> We have a 2 DC cluster where the keyspaces are replicated between the
>>>> 2. Is it possible to add a keyspace to one of the DCs that won't be
>>>> replicated to the other?
>>>>
>>>> Whenever we add a new keyspace it seems to get replicated even if we
>>>> don't specify the other DC in the keyspace's NetworkTopologyStrategy.
>>>>
>>>> -J
>>>>
>>> --
>>> 
>>> Ben Slater
>>> Chief Product Officer
>>> Instaclustr: Cassandra + Spark - Managed | Consulting | Support
>>> +61 437 929 798
>>>
>>
>> --
> 
> Ben Slater
> Chief Product Officer
> Instaclustr: Cassandra + Spark - Managed | Consulting | Support
> +61 437 929 798
>

Re: Multi-DC Cluster w/ non-replicated Keyspace

[Jason J. W. Williams]

Hey Ben,

Looks like just the schema. I was surprised that running SELECTs against
the DC which should not have any data (because it's not specified in
NetworkTopologyStrategy), actually returned data. But looking at the query
trace it looks like its forwarding the queries to the other DC.

-J

On Thu, Jun 16, 2016 at 7:55 PM, Ben Slater <ben.sla...@instaclustr.com>
wrote:

> Do you mean the data is getting replicated or just the schema?
>
> On Fri, 17 Jun 2016 at 11:48 Jason J. W. Williams <
> jasonjwwilli...@gmail.com> wrote:
>
>> Hi Guys,
>>
>> We have a 2 DC cluster where the keyspaces are replicated between the 2.
>> Is it possible to add a keyspace to one of the DCs that won't be replicated
>> to the other?
>>
>> Whenever we add a new keyspace it seems to get replicated even if we
>> don't specify the other DC in the keyspace's NetworkTopologyStrategy.
>>
>> -J
>>
> --
> 
> Ben Slater
> Chief Product Officer
> Instaclustr: Cassandra + Spark - Managed | Consulting | Support
> +61 437 929 798
>

Multi-DC Cluster w/ non-replicated Keyspace

[Jason J. W. Williams]

Hi Guys,

We have a 2 DC cluster where the keyspaces are replicated between the 2. Is
it possible to add a keyspace to one of the DCs that won't be replicated to
the other?

Whenever we add a new keyspace it seems to get replicated even if we don't
specify the other DC in the keyspace's NetworkTopologyStrategy.

-J

Re: Most stable version?

[Jason J. W. Williams]

Thanks for the advice Carlos. Do appreciate it.

-J

On Fri, Apr 22, 2016 at 1:23 PM, Carlos Rolo  wrote:

> I do expect 3 to get stable at some point, according to documentation it
> will be the 3.0.x series. But the current 3.x tick-tock,  I would recommend
> a jump into it when Datastax do it. Otherwise, maybe 4 might get stable and
> we could be following similar releases cicles like some software out there,
> even is stable (2 and 4) even is unstable (3 and 5). But this is my
> guessing. Wait for a DSE release on 3.x and use that.
>
> I had problems in earlier 2.2, 2.2.5 seems to be a solid release, but I
> will wait for 2.2.6 before recommending for production. Just to be safe :)
>
> Regards,
>
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>
> Pythian - Love your data
>
> rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
> *
> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
> www.pythian.com
>
> On Fri, Apr 22, 2016 at 6:42 PM, Jason Williams  > wrote:
>
>> Hi Carlos,
>>
>> I read your blog post (actually almost everything I can find on tick
>> tock). My understanding has been tick tock will be the only versioning
>> going forward.
>>
>> Or are you suggesting at some point there will be a stable train for 3?
>> (or that 3.x will be bumped to 4.0 when stable)?
>>
>> We're on 2.2.5 and haven't seen any major problems with it.
>>
>> -J
>>
>>
>>
>> Sent via iPhone
>>
>> On Apr 22, 2016, at 03:34, Carlos Rolo  wrote:
>>
>> If you need SASI, you need to use 3.4+. 3.x will always be "unstable" (It
>> is explained why in my blog post). You get those odd versions, but it is
>> not a solid effort to stabilize the platform, otherwise devs would not jump
>> to 3.6, and keep working on 3.5. And then you get 3.7, which might fix some
>> issues of 3.4+, but next month you get 3.8 unstable again... I'm waiting to
>> see where this is going. I only had bad experiences with 3.x series atm.
>>
>> If you want stability (and no new features), you would use 2.1.13.
>>
>> 2.2.x is kind of a mixed bag, no really huge improvements over 2.1.x
>> series and it is still having some issues, so I would stick to 2.1.x
>> series.
>>
>> Regards,
>>
>> Carlos Juzarte Rolo
>> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>>
>> Pythian - Love your data
>>
>> rolo@pythian | Twitter: @cjrolo | Linkedin: 
>> *linkedin.com/in/carlosjuzarterolo
>> *
>> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
>> www.pythian.com
>>
>> On Fri, Apr 22, 2016 at 10:16 AM, Jason Williams <
>> jasonjwwilli...@gmail.com> wrote:
>>
>>> My reading of the tick-rock cycle, is that we've moved from a stable
>>> train that receives mostly bug fixes until the next major stable, to one
>>> where every odd minor version is a bug fix-only...likely mostly for the
>>> previous even. The goal being a relatively continuously stable code base in
>>> odd minor versions.
>>>
>>> In that environment where there is no "stable" train, would the right
>>> approach be to pick the feature set needed and then choose the odd minor
>>> where that feature set had been stable for 2-3 previous odd minors.
>>>
>>> For example, SASI was added in 3.4, so 3.5 is the first bug fix only
>>> (odd minor) containing it. By the logic above you wouldn't want to use SASI
>>> in production until 3.9 or later. Or is my logic about how to treat
>>> tick-tock off base?
>>>
>>> -J
>>>
>>>
>>> Sent via iPhone
>>>
>>> On Apr 22, 2016, at 01:46, Satoshi Hikida  wrote:
>>>
>>> Hi,
>>>
>>> I'm also looking for the most stable version of the Cassandra, too. I
>>> read Carlos's blog post. According to his article, I guess 2.1.x is the
>>> most stable version, is it right? I prefer to use the most stable version
>>> rather than many advanced features. For satisfy my purpose, should I use
>>> 2.1.X? or latest 2.2.x is recommended?
>>>
>>> Currently I use 2.2.5, but is the latest 2.1.13 recommended for
>>> production use?
>>>
>>> Regards,
>>> Satoshi
>>>
>>>
>>> On Mon, Apr 18, 2016 at 11:45 PM, Carlos Rolo  wrote:
>>>
 Sorry to resurrect this now, but I don't consider anything after 3.0.x
 stable.

 I wrote a blog post about this to be clear:
 https://www.pythian.com/blog/cassandra-version-production/

 Use it and pick a version based on your needs.

 Regards,

 Carlos Juzarte Rolo
 Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

 Pythian - Love your data

 rolo@pythian | Twitter: @cjrolo | Linkedin: 
 *linkedin.com/in/carlosjuzarterolo
 *
 Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
 www.pythian.com

 On Fri, Apr 15, 2016 at 12:44 PM, Jean Tremblay <
 

Re: Optional TLS CQL Encryption

[Jason J. W. Williams]

Hi Ben,

Thanks for confirming what I saw occur. The Datastax drivers don't play
very nicely with Twisted Python so connection pooling is inconsistent and
makes always-on TLS a no-go performance-wise. The encryption overhead isn't
the problem, it's the build-up of the TLS session for every connection when
connection pooling is not working as needed. That said it is still
beneficial to be able to enforce TLS for remote access...MySQL allows you
to enforce TLS on a per-user basis for example.

If someone has been successful not wrapping the Datastax drivers in
deferToThread calls when using Twisted I'd appreciate insight on how you
got that working because its pretty much undocumented.

-J

On Tue, Apr 19, 2016 at 11:46 PM, Ben Bromhead <b...@instaclustr.com> wrote:

> Hi Jason
>
> If you enable encryption it will be always on. Optional encryption is
> generally a bad idea (tm). Also always creating a new session every query
> is also a bad idea (tm) even without the minimal overhead of encryption.
>
> If you are really hell bent on doing this you could have a node that is
> part of the cluster but has -Dcassandra.join_ring=false set in jvm
> options in cassandra-env.sh so it does not get any data and configure
> that to have no encryption enabled. This is known as a fat client. Then
> connect to that specific node whenever you want to do terrible non
> encrypted things.
>
> Having said all that, please don't do this.
>
> Cheers
>
> On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams <
> jasonjwwilli...@gmail.com> wrote:
>
>> Hey Guys,
>>
>> Is there a way to make TLS encryption optional for the CQL listener? We'd
>> like to be able to use for remote management connections but not for same
>> datacenter usage (since the build/up  tear down cost is too high for things
>> that don't use pools).
>>
>> Right now it appears if we enable encryption it requires it for all
>> connections, which definitely is not what we want.
>>
>> -J
>>
> --
> Ben Bromhead
> CTO | Instaclustr <https://www.instaclustr.com/>
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>

Optional TLS CQL Encryption

[Jason J. W. Williams]

Hey Guys,

Is there a way to make TLS encryption optional for the CQL listener? We'd
like to be able to use for remote management connections but not for same
datacenter usage (since the build/up  tear down cost is too high for things
that don't use pools).

Right now it appears if we enable encryption it requires it for all
connections, which definitely is not what we want.

-J

Re: Cassandra security using openssl or keytool

[Jason J. W. Williams]

>
> Google words like :
>
> "
> import openssl private key into keytool
> "
>
> Find results like :
>
>
> http://stackoverflow.com/questions/906402/importing-an-existing-x509-certificate-and-private-key-in-java-keystore-to-use-i/8224863#8224863
>
>
I wasted 4-5 hours of my life recently importing an OpenSSL key in a PEM
into a Cassandra keystore using exactly that article as a starting point
(the server's hostname already had a certificate and key in our ops CA, and
for various reasons we didn't want to revoke and reissue it.).

Even when you get the key imported, keytool will then frequently refuse to
pair that key entry with the certificate when you import the
certificate...and it will instead store the certificate in a new keystore
entry. Which won't work because the alias names on the keystore entries for
the key and certificate will be different (you need one entry storing both
key and certificate).  I did _finally_ get it to work but I can't tell you
how I did it...it was a lot of manually editing PEM files, converting them
to DERs and then trying every possible combination of keytool import flags.

-J

Re: Cassandra security using openssl or keytool

[Jason J. W. Williams]

>
> I certainly don't vouch for the advisability of attempting a task you've
> described as a "real pain" ... but if OP wants/needs to, it's their
> funeral? :D
>

Agreed. I just wanted to elaborate what a "real pain" meant so OP would
know I wasn't just blowing him off.

-J

Re: Verifying internode SSL

[Jason J. W. Williams]

Awesome. Thanks Nate!

On Tue, Oct 13, 2015 at 10:32 AM, Nate McCall 
wrote:

> > I've configured internode SSL and set it to be used between datacenters
> only. Is there a way in the logs to verify SSL is operating between nodes
> in different DCs or do I need to break out tcpdump?
> >
>
> Even on DC only encryption, you should see the following message in the
> log:
>
> "Starting Encrypted Messaging Service on SSL port 7001"
>
> With any Java-based thing using SSL, you can always use the following
> startup parameter to find out exactly what is going in:
>
> -Djavax.net.debug=ssl
>
> This page will tell you how to interpret the debug output:
>
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
>
> --
> -
> Nate McCall
> Austin, TX
> @zznate
>
> Co-Founder & Sr. Technical Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>