Hi community,
Wonder if you can help me.
I have a cluster on v3.0.11 I am planning to upgrade this to 3.10.
Is rolling back the binaries a viable solution?
From reading blogs and such, I’ve read that downgrading is a no-no. Whilst it
is possible literally and in theory possible, many of the
> I have a cluster on v3.0.11 I am planning to upgrade this to 3.10.
> Is rolling back the binaries a viable solution?
What's the goal with moving form 3.0 to 3.x?
Also, our latest release in 3.x is 3.11.3 and has a couple of
important bug fixes over 3.10 (which is a bit dated at this point).
Since i failed to find a document on how to configure and use the Token
Allocation Algorithm (to replace the random Algorithm), just wanted to be sure
about the procedure i've done: 1. Using Apache Cassandra 3.11.2 2. Configured
one of seed nodes with num_tokens=8 and started it. 3. Using Cqlsh
> We only increased commitlog_total_space_in_mb so that Cassandra fully uses
> the dedicated disk, but that may be an error?
> The default value for this setting is (per the documentation):
>
> The default value is the smaller of 8192, and 1/4 of the total space of
> the commitlog volume.
>
We'll start publishing snapshot builds in the near future to ease
testing (support for such just added via CASSANDRA-12704).
On Sun, Sep 30, 2018 at 5:11 AM James Carman wrote:
>
> Okay, cool. So, 4.0.0-SNAPSHOT doesn’t have Java 11 support quite yet? No
> big deal. Just trying to get ahead
Definitely don’t go to 3.10, go to 3.11.3 or newest 3.0 instead
--
Jeff Jirsa
On Sep 30, 2018, at 5:29 PM, Nate McCall wrote:
>> I have a cluster on v3.0.11 I am planning to upgrade this to 3.10.
>> Is rolling back the binaries a viable solution?
>
> What's the goal with moving form 3.0 to
Hi,
Cassandra's documentation has several recommendations for moving the commit
log directory to a dedicated disk, separated from the sstables disk(s).
However, I couldn't find much information on what would be good practices
regarding this dedicated commit log disk and I'm wondering how to