Very soon. If not today, it will be up tomorrow. :)
Yayyy, just saw the release of 3.11.4. :-)
You'll need to go to v3 for 3.11. Congratulations on being aware enough to
do this - advanced upgrade coordination, it's absolutely the right thing to
do, but most people don't know it's possible or
The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.1.21.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source
The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.2.14.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source
The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.0.18.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source
The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.11.4.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source
Hello,
By the way, about https://issues.apache.org/jira/browse/CASSANDRA-13418, I'm
not sure how to apply this solution.
Do you have a guide about it?
Regards,
Osman
On 12.02.2019 01:42, Nitan Kainth wrote:
That’s right Jeff. That’s why I am thinking why not compaction gets rid of old
That’s right Jeff. That’s why I am thinking why not compaction gets rid of old
exited sstables?
Regards,
Nitan
Cell: 510 449 9629
> On Feb 11, 2019, at 3:53 PM, Jeff Jirsa wrote:
>
> It's probably not safe. You shouldn't touch the underlying sstables unless
> you're very sure you know what
unsubscribe
–Ben Standefer
Sent via Superhuman ( https://sprh.mn/?vip=benstande...@gmail.com )
It's probably not safe. You shouldn't touch the underlying sstables unless
you're very sure you know what you're doing.
On Mon, Feb 11, 2019 at 1:05 PM Akash Gangil wrote:
> I have in the past tried to delete SSTables manually, but have noticed
> bits and pieces of that data still remain, even
I have in the past tried to delete SSTables manually, but have noticed bits
and pieces of that data still remain, even though the sstables of that
window is deleted. So always wondered if playing directly with the
underlying filesystem is a safe bet?
On Mon, Feb 11, 2019 at 1:01 PM Jonathan
Deleting SSTables manually can be useful if you don't know your TTL up
front. For example, you have an ETL process that moves your raw Cassandra
data into S3 as parquet files, and you want to be sure that process is
completed before you delete the data. You could also start out without
setting a
Jeff,
It means we have to delete sstables manually?
Regards,
Nitan
Cell: 510 449 9629
> On Feb 11, 2019, at 2:40 PM, Jeff Jirsa wrote:
>
> There's a bit of headache around overlapping sstables being strictly safe to
> delete. https://issues.apache.org/jira/browse/CASSANDRA-13418 was added
thanks for the pointer Jeff
On Mon, Feb 11, 2019 at 9:40 PM Jeff Jirsa wrote:
> There's a bit of headache around overlapping sstables being strictly safe
> to delete. https://issues.apache.org/jira/browse/CASSANDRA-13418 was
> added to allow the "I know it's not technically safe, but just
There's a bit of headache around overlapping sstables being strictly safe
to delete. https://issues.apache.org/jira/browse/CASSANDRA-13418 was added
to allow the "I know it's not technically safe, but just delete it anyway"
use case. For a lot of people who started using TWCS before 13418, "stop
Hi,
In regards to comment “Purging data is also straightforward, just dropping
SSTables (by a script) where create date is older than a threshold, we don't
even need to rely on TTL”
Doesn’t the old sstables drop by itself? One ttl and gc grace seconds past
whole sstable will have only
No worry for overlapping, the use-case is about events/timeseries and there
is almost no delay so it should be fine.
On the note-side, since we have the guarantee to have 1 SSTable/day of
ingestion, this is very easy to "emulate" incremental backup. You just need
to find the generated SSTable
Wild ass guess based on a large use case I knew about at the time
If you go above that, I expect it’d largely be fine as long as you were sure
they weren’t overlapping so reads only ever touched a small subset of the
windows (ideally 1).
If you have one day windows and every read touches all
Hello users
On the official documentation for TWCS (
http://cassandra.apache.org/doc/latest/operating/compaction.html#time-window-compactionstrategy)
it is advised to select the windows unit and size so that the total number
of windows intervals is around 20-30.
Is there any explanation for this
On 2/11/19 9:24 AM, shalom sagges wrote:
> I've successfully upgraded a 2.0 cluster to 2.1 on the way to upgrade to
> 3.11 (hopefully 3.11.4 if it'd be released very soon).
Very soon. If not today, it will be up tomorrow. :)
--
Michael
On Mon, Feb 11, 2019 at 7:24 AM shalom sagges
wrote:
> Hi All,
>
> I've successfully upgraded a 2.0 cluster to 2.1 on the way to upgrade to
> 3.11 (hopefully 3.11.4 if it'd be released very soon).
>
> I have 2 small questions:
>
>1. Currently the Datastax clients are enforcing Protocol
Hello Team,
I have been trying to use sjk tool/jmxterm jar utilities to change
compaction strategy of a table locally from STCS to LCS, without changing
the schema.
I have been trying this on a lower environment first before implementing
the same in production environment.
The change did work on
Hi All,
I've successfully upgraded a 2.0 cluster to 2.1 on the way to upgrade to
3.11 (hopefully 3.11.4 if it'd be released very soon).
I have 2 small questions:
1. Currently the Datastax clients are enforcing Protocol Version 2 to
prevent mixed cluster issues. Do I need now to enforce
Thank you
On Sun, Feb 10, 2019, 5:46 PM Sri Rathan Rangisetti <
srirathan.rangise...@gmail.com> wrote:
> It will be part of cassandra startup script, of you are using RHEL its
> located at /etc/inti.d/cassandra
>
>
> Regards
> Sri Rathan
>
> On Sun, Feb 10, 2019, 2:45 PM Rahul Reddy
> wrote:
>
I would strongly suggest you consider an upgrade to 3.11.x. I found it
decreased space needed by about 30% in addition to significantly lowering
GC.
As a first step, though, why not just revert to CMS for now if that was
working ok for you? Then you can convert one host for diagnosis/tuning so
24 matches
Mail list logo
