Found issue - num tokens was set incorrectly in my container. Upgrade
successful!
-Joe
On 11/5/2024 2:27 PM, Joe Obernberger wrote:
Hi all - getting an error trying to upgrade our 4.x cluster to 5. The
following message repeats over and over and then the pod crashes:
Heap dump creation on u
Thanks Scott for the reply.
Regards
Manish
On Sun, Jan 7, 2024 at 12:02 PM C. Scott Andreas
wrote:
> Upgrading from 3.11.x to 4.1.x is supported, yes. As the documentation
> you reference mentions, it is not possible to downgrade from 4.x to 3.x.
>
> Note that running repair during upgrades is
Upgrading from 3.11.x to 4.1.x is supported, yes. As the documentation you
reference mentions, it is not possible to downgrade from 4.x to 3.x.
Note that running repair during upgrades is not supported; please ensure it is
disabled before beginning the upgrade and re-enable after.
– Scott
> O
21:08
To: user@cassandra.apache.org
Subject: Re: Upgrade from C* 3 to C* 4 per datacenter
Just a heads-up, but there have been issues (at least one) reported when
upgrading a multi-DC cluster from 3.x to 4.x when the cluster uses node-to-node
SSL/TLS encryption. This is largely attributed to the
Just a heads-up, but there have been issues (at least one) reported when
upgrading a multi-DC cluster from 3.x to 4.x when the cluster uses
node-to-node SSL/TLS encryption. This is largely attributed to the fact
that the secure port in 4.x changes to 9142, whereas in 3.x it continues to
run on 9042
Hi,
as we are currently facing the same challenge (upgrading an existing cluster
from C* 3 to C* 4), I wanted to share our strategy with you. It largely is what
Scott already suggested, but I have some extra details, so I thought it might
still be useful.
We duplicated our cluster using the st
Hello Jeff et al,
Thanks a lot for your valuable info. Your comment covers all my queries.
BR
MK
From: Jeff Jirsa
Sent: October 26, 2023 15:48
To: user@cassandra.apache.org
Cc: Michalis Kotsiouros (EXT)
Subject: Re: Upgrade from C* 3 to C* 4 per datacenter
On Oct 26, 2023, at 12:32 AM
> On Oct 26, 2023, at 12:32 AM, Michalis Kotsiouros (EXT) via user
> wrote:
>
>
> Hello Cassandra community,
> We are trying to upgrade our systems from Cassandra 3 to Cassandra 4. We plan
> to do this per data center.
> During the upgrade, a cluster with mixed SW levels is expected. At thi
@cassandra.apache.org
Cc: user@cassandra.apache.org; Michalis Kotsiouros (EXT)
Subject: Re: Upgrade from C* 3 to C* 4 per datacenter
The recommended approach to upgrading is to perform a replica-safe rolling
restart of instances in each datacenter, one datacenter at a time.
> In case of an upgr
The recommended approach to upgrading is to perform a replica-safe rolling restart of instances in
each datacenter, one datacenter at a time. > In case of an upgrade failure, would it be possible
to remove the data center from the cluster, restore the datacenter to C*3 SW and add it back to
clu
You can check in your lower environment.
On Fri, 11 Aug, 2023, 06:25 Surbhi Gupta, wrote:
> Thanks,
>
> I am looking to to upgrade to 4.1.x .
> Please advise.
>
> Thanks
> Surbhi
>
> On Thu, Aug 10, 2023 at 5:39 PM MyWorld wrote:
>
>> Though it's recommended to upgrade to latest version of 3.11
Thanks,
I am looking to to upgrade to 4.1.x .
Please advise.
Thanks
Surbhi
On Thu, Aug 10, 2023 at 5:39 PM MyWorld wrote:
> Though it's recommended to upgrade to latest version of 3.11.x and then to
> ver 4 but even upgrading directly won't be a problem. Just check the
> release notes.
>
> Ho
Though it's recommended to upgrade to latest version of 3.11.x and then to
ver 4 but even upgrading directly won't be a problem. Just check the
release notes.
However for production, I would recommend to go for 4.0.x latest stable
version.
Regards
Ashish
On Sat, 8 Jul, 2023, 05:44 Surbhi Gupta,
Assuming "do it in one go" means a rolling upgrade from 3.11.5 to 4.1.2
skipping all version numbers between these two, the answer is yes, you
can "do it in one go".
On 08/07/2023 01:14, Surbhi Gupta wrote:
Hi,
We have to upgrade from 3.11.5 to 4.1.x .
Can we do it in one go ?
Or do we have t
You should take a snapshot before starting the upgrade process. You
cannot achieve a snapshot of "the most current situation" in a live
cluster anyway, as data are constantly written to the cluster even after
a node is stopped for upgrading. So you've gotta to accept the outdated
snapshots if y
Please read
https://docs.datastax.com/en/upgrading/docs/datastax_enterprise/upgrdCstarToDSE.html#_general_restrictions
The document is written for DSE Cassandra, but must of it applies to
Apache Cassandra too.
In short, watch out for these:
Client side:
* Check client driver compatibility.
Groovy. Thanks.
From: Erick Ramirez
Sent: Wednesday, October 12, 2022 4:08 PM
To: user@cassandra.apache.org
Subject: Re: Upgrade
EXTERNAL
That's correct. Cheers!
That's correct. Cheers!
On every node?
From: Erick Ramirez
Sent: Wednesday, October 12, 2022 3:20 PM
To: user@cassandra.apache.org
Subject: Re: Upgrade
EXTERNAL
It's just a minor patch upgrade so all you're really upgrading is the binaries.
In any case, switching off replication is not the recommended app
It's just a minor patch upgrade so all you're really upgrading is the
binaries. In any case, switching off replication is not the recommended
approach. The recommended pre-upgrade procedure is to take backups of the
data on your nodes with nodetool snapshot. Cheers!
>
> Thank you for that clarification, Erick. So do i understand correctly,
> that because of the upgrade the host id changed and therefore differs from
> the ones in the sstables where the old host id is still sitting until a
> sstable upgrade?
>
Not quite. :) The host ID will never change for the
Am Fr., 13. Mai 2022 um 12:05 Uhr schrieb Erick Ramirez <
erickramire...@apache.org>:
> It's expected and is nothing to worry about. From C* 3.0.25/3.11.11/4.0,
> the SSTables now contain the host ID on which they were created to prevent
> loss of commitlog data when SSTables are moved/copied to o
It's expected and is nothing to worry about. From C* 3.0.25/3.11.11/4.0,
the SSTables now contain the host ID on which they were created to prevent
loss of commitlog data when SSTables are moved/copied to other nodes
(CASSANDRA-16619). That's why the message is logged at WARN level instead
of ERROR
The general advice is to always upgrade to 3.11.latest before upgrading to
4.0.latest. It is possible to upgrade from an older 3.11 version but you'll
probably run into known issues already fixed in the latest version.
Also, we recommend you run upgradesstables BEFORE upgrading to 4.0.latest
-- th
1:00 AM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: Upgrade strategy for high number of nodes
Thanks for pointer. We haven't much changed data model since long, so before
workarounds (scrub) worth understanding root cause of problem.
This might be reason why running upgradesstabl
Thanks for pointer. We haven't much changed data model since long, so
before workarounds (scrub) worth understanding root cause of problem.
This might be reason why running upgradesstables in parallel was not
recommended.
-Shishir
On Sat, 30 Nov 2019, 10:37 Jeff Jirsa, wrote:
> Scrub really shou
Scrub really shouldn’t be required here.
If there’s ever a step that reports corruption, it’s either a very very old
table where you dropped columns previously or did something “wrong” in the past
or a software bug. The old dropped column really should be obvious in the stack
trace - anything
Some more background. We are planning (tested) binary upgrade across all
nodes without downtime. As next step running upgradesstables. As C*
file format and version (from format big, version mc to format bti, version
aa (Refer
https://docs.datastax.com/en/dse/6.0/dse-admin/datastax_enterprise/tools
Hello Shishir,
It shouldn't be necessary to take downtime to perform upgrades of a
Cassandra cluster. It sounds like the biggest issue you're facing is the
upgradesstables step. upgradesstables is not strictly necessary before a
Cassandra node re-enters the cluster to serve traffic; in my experien
To further clarify @carl.mueller's comments above, it would appear that
both the initial jump in metrics (and subsequent drop) was app-related, not
cassandra related.
On Tue, Jun 25, 2019 at 1:45 PM Carl Mueller
wrote:
> Nevermind, it would appear once we looked further out on the metrics there
Nevermind, it would appear once we looked further out on the metrics there
was some huge bump about a month ago from the levels we see now
On Tue, Jun 25, 2019 at 1:35 PM Carl Mueller
wrote:
> Oh we are 2.2.13 currently, seems to be 3.7.1 for the java-driver
>
> On Tue, Jun 25, 2019 at 1:11 PM
Oh we are 2.2.13 currently, seems to be 3.7.1 for the java-driver
On Tue, Jun 25, 2019 at 1:11 PM Carl Mueller
wrote:
> We have an app that needs to be pinned to v3 protocol for the upgrade to
> 3.11.X
>
> ... we rolled out the v3 "pinning" and the amount of write counts and
> network traffice p
Not sure where the binaries were obtained from. I am helping a friend who
is not part of this DL.
based on understanding, i proposed above mentioned plan wanted to hear
others' opinions.
On Mon, Jun 24, 2019 at 6:06 AM Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> On Fri, Jun 21, 20
On Fri, Jun 21, 2019 at 7:02 PM Nitan Kainth wrote:
>
> we upgraded binaries from 3.0 to 4.0.
>
Where did you get the binaries for 4.0? It is not released officially yet,
so I guess you were using SVN trunk? Or was there a pre-release?
we run major compaction periodically for some valid reaso
Hi Kenneth,
Thanks for your interest to help. I had to take a decision quick because it
was a production cluster. So, long story short, I let the cluster finish
the decommission process before touching it. When decommissioned node left
the cluster I did a rolling restart and the nodes start behavi
Hi John,
Was the cluster running ok before decommissioning the node?
Why were you decommissioning the node?
Were you upgrading from 3.11.1 to 3.11.4?
From: Ioannis Zafiropoulos [mailto:john...@gmail.com]
Sent: Wednesday, February 27, 2019 7:33 AM
To: user@cassandra.apache.org
Subject
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 use
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 Versio
Thanks a lot Anuj!
On Wed, Jan 16, 2019 at 4:56 PM Anuj Wadehra wrote:
> Hi Shalom,
>
> Just a suggestion. Before upgrading to 3.11.3 make sure you are not
> impacted by any open crtitical defects especially related to RT which may
> cause data loss e.g.14861.
>
> Please find my response below
Hi Shalom,
Just a suggestion. Before upgrading to 3.11.3 make sure you are not impacted by
any open crtitical defects especially related to RT which may cause data loss
e.g.14861.
Please find my response below:
The upgrade process that I know of is from 2.0.14 to 2.1.x (higher than 2.1.9 I
thin
completed. So, I push to get upgradesstables completed as soon as possible.
Sean Durity
From: Shravan R
Sent: Tuesday, December 04, 2018 3:39 PM
To: user@cassandra.apache.org
Subject: Re: [EXTERNAL] Re: upgrade Apache Cassandra 2.1.9 to 3.0.9
Thanks Sean. I have automation in place that can put
> process/automation in place. The upgrade process should not be a reason to
> delay, especially for minor version upgrades that might be quickly
> necessary (security issue or bug fix).
>
>
>
>
>
> Sean Durity
>
>
>
> *From:* Shravan R
> *Sent:* Tuesday, Dec
Schema won’t be transferred cross-majors
--
Jeff Jirsa
> On Dec 4, 2018, at 10:51 PM, Shravan R wrote:
>
> Thanks Jeff. I tried to bootstrap a 3.x node to a partially upgraded cluster
> (2.1.9 + 3.x) and I was not able to do so. The schema never settled.
>
> How does the below approach so
quickly necessary (security issue or bug
fix).
Sean Durity
From: Shravan R
Sent: Tuesday, December 04, 2018 12:22 PM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: upgrade Apache Cassandra 2.1.9 to 3.0.9
Thanks Jeff. I tried to bootstrap a 3.x node to a partially upgraded cluster
(2.1.9
Thanks Jeff. I tried to bootstrap a 3.x node to a partially upgraded
cluster (2.1.9 + 3.x) and I was *not* able to do so. The schema never
settled.
How does the below approach sound like?
1. Update the software binary on all nodes to use cassandra-3.x upon a
restart.
2. Restart all nodes
> On Dec 2, 2018, at 12:40 PM, Shravan R wrote:
>
> Marc/Dimitry/Jon - greatly appreciate your feedback. I will look into the
> version part that you suggested. The reason to go direct to 3.x is to take a
> bi leap and reduce overall effort to upgrade a large cluster (development
> included)
Marc/Dimitry/Jon - greatly appreciate your feedback. I will look into the
version part that you suggested. The reason to go direct to 3.x is to take
a bi leap and reduce overall effort to upgrade a large cluster (development
included).
I have these questions from my original post. Appreciate if yo
Dmitry is right. Generally speaking always go with the latest bug fix
release.
On Sat, Dec 1, 2018 at 10:14 AM Dmitry Saprykin
wrote:
> See more here
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-13004
>
> On Sat, Dec 1, 2018 at 1:02 PM Dmitry Saprykin
> wrote:
>
>> Ev
See more here
https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-13004
On Sat, Dec 1, 2018 at 1:02 PM Dmitry Saprykin
wrote:
> Even more, 3.0.9 is a terrible target choice by itself. It has a nasty bug
> corrupting sstables on alter.
>
> On Sat, Dec 1, 2018 at 11:55 AM Marc Se
Even more, 3.0.9 is a terrible target choice by itself. It has a nasty bug
corrupting sstables on alter.
On Sat, Dec 1, 2018 at 11:55 AM Marc Selwan
wrote:
> Hi Shravan,
>
> Did you upgrade Apache Cassandra 2.1.9 to the latest patch release before
> doing the major upgrade? It's generally favora
Hi Shravan,
Did you upgrade Apache Cassandra 2.1.9 to the latest patch release before
doing the major upgrade? It's generally favorable to go to the latest patch
release as often times they include fixes that smooth over the upgrade
process. There are hundreds of bug fixes between 2.1.9 and 2.1.20
Hello,
You might want to have a look at
https://issues.apache.org/jira/browse/CASSANDRA-14823
It seems that you could face a *data loss* while upgrading to Cassandra
3.11.3. Apparently, it is still somewhat unsafe to upgrade Cassandra to
C*3, even if you use the latest C*3.0.17/3.11.3. According
Hi,
Yes you can upgrade from 2.2 to 3.11.3
The steps for upgrade are there on lots of blogs and sites.
You can follow:
https://myopsblog.wordpress.com/2017/12/04/upgrade-cassandra-cluster-from-2-x-to-3-x/
You should read the NEWS.txt for information on any release while planning
for upgrade.
h
ctions are under control and normal. This may not be related to
upgrade at all!
From: Pradeep Chhetri [mailto:prad...@stashaway.com]
Sent: Tuesday, August 28, 2018 3:32 AM
To: user@cassandra.apache.org
Subject: Re: Upgrade from 2.1 to 3.11
You may want to try upgrading to 3.11.3 instead
may not be related to upgrade at all!
>
>
>
>
>
> *From:* Pradeep Chhetri [mailto:prad...@stashaway.com]
> *Sent:* Tuesday, August 28, 2018 3:32 AM
> *To:* user@cassandra.apache.org
> *Subject:* Re: Upgrade from 2.1 to 3.11
>
>
>
> You may want to try upgrading to 3
...@stashaway.com]
Sent: Tuesday, August 28, 2018 3:32 AM
To: user@cassandra.apache.org
Subject: Re: Upgrade from 2.1 to 3.11
You may want to try upgrading to 3.11.3 instead which has some memory leaks
fixes.
On Tue, Aug 28, 2018 at 9:59 AM, Mun Dega
mailto:mundeg...@gmail.com>> wrote:
I am surprise
Ma, did you try what Mohamadreza suggested? Have a such a large heap means
you are getting a ton of stuff that needs full GC.
On Tue, Aug 28, 2018 at 4:31 AM Pradeep Chhetri
wrote:
> You may want to try upgrading to 3.11.3 instead which has some memory
> leaks fixes.
>
> On Tue, Aug 28, 2018 at
You may want to try upgrading to 3.11.3 instead which has some memory leaks
fixes.
On Tue, Aug 28, 2018 at 9:59 AM, Mun Dega wrote:
> I am surprised that no one else ran into any issues with this version. GC
> can't catch up fast enough and there is constant Full GC taking place.
>
> The result
I am surprised that no one else ran into any issues with this version. GC
can't catch up fast enough and there is constant Full GC taking place.
The result? unresponsive nodes makeing entire cluster unusable.
Any insight on this issue from anyone that is using this version would be
appreciated.
You have very large heap,it’s take most of cpu time in GC stage.you should
in maximum set heap on 12GB and enable row cache to your cluster become
faster.
On Friday, 24 August 2018, Mun Dega wrote:
> 120G data
> 28G heap out of 48 on system
> 9 node cluster, RF3
>
>
> On Thu, Aug 23, 2018, 17:1
Looks like there are a couple of issues open regarding 3.11.2 release:
https://issues.apache.org/jira/browse/CASSANDRA-14355
https://issues.apache.org/jira/browse/CASSANDRA-14495
Ma
On Thu, Aug 23, 2018 at 10:54 PM Mun Dega wrote:
> Interesting. Any other suggestions what other things change
Interesting. Any other suggestions what other things changed that would be
major between 2.1 and 3.x?
In Change Log all isee is bug fixes and further improvements.
On Thu, Aug 23, 2018, 21:37 Gosar M wrote:
> we also increased the max_heap_count (sysctl.conf) value to resolve OOO
> memory is
we also increased the max_heap_count (sysctl.conf) value to resolve OOO memory
issue.
On Thursday, 23 August 2018, 16:04:20 GMT-7, Mun Dega
wrote:
120G data28G heap out of 48 on system9 node cluster, RF3
On Thu, Aug 23, 2018, 17:19 Mohamadreza Rostami
wrote:
Hi,How much data do you
120G data
28G heap out of 48 on system
9 node cluster, RF3
On Thu, Aug 23, 2018, 17:19 Mohamadreza Rostami <
mohamadrezarosta...@gmail.com> wrote:
> Hi,
> How much data do you have? How much RAM do your servers have? How much do
> you have a heep?
> On Thu, Aug 23, 2018 at 10:14 PM Mun Dega wro
Hi,
How much data do you have? How much RAM do your servers have? How much do
you have a heep?
On Thu, Aug 23, 2018 at 10:14 PM Mun Dega wrote:
> Hello,
>
> We recently upgraded from Cassandra 2.1 to 3.11.2 on one cluster. The
> process went OK including upgradesstable but we started to experien
We found the solution for our High read volume bytes with help of DSE, we made
following change
$ lvchange -r 16
Following parameter in cassandra.yaml:-
disk_access_mode: mmap_index_only
Thank you.
On Monday, 13 August 2018, 10:39:28 GMT-7, kooljava2
wrote:
We did run "nodetool
We did run "nodetool upgradesstables" on all nodes. The C* version is 3.0.15
Thank you.
On Saturday, 11 August 2018, 21:47:52 GMT-7, Elliott Sims
wrote:
Might be a silly question, but did you run "nodetool upgradesstables" and
convert to the 3.0 format? Also, which 3.0? Newest, or a
Might be a silly question, but did you run "nodetool upgradesstables" and
convert to the 3.0 format? Also, which 3.0? Newest, or an earlier 3.0.x?
On Fri, Aug 10, 2018 at 3:05 PM, kooljava2
wrote:
> Hello,
>
> We recently upgrade C* from 2.1 to 3.0. After the upgrade we are seeing
> increase i
技有限公司
> Virtue Intelligent Network Ltd, co.
>
> Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
> Mob: +86 13797007811|Tel: + 86 27 5024 2516
>
> 发件人: Hannu Kröger
> 发送时间: 2018年5月3日 15:00
> 收件人: user
> 主题: Re: upgrade from 3.9 to 3.11.2
>
> He
Hello,
it never hurts to run “nodetool upgradesstables" after the upgrade. It’s a
no-op if there is nothing to upgrade.
Hannu
> On 3 May 2018, at 09:57, Xiangfei Ni wrote:
>
> Hi Community
> I have a question regarding upgrading Cassandra from 3.9 to 3.11.2,
> Do I need to run nodetool up
Hi Lucas,
There are usually some logs in system.log at node startup regarding JMX
initialization, are those OK ?
On 5 April 2018 at 22:13, Lucas Benevides
wrote:
> Dear community members,
>
> I have just upgraded my Cassandra from version 3.11.1 to 3.11.2. I kept my
> previous configuration fil
I have finally tracked down the problem and I'm happy to say that this
is not a Cassandra problem. I found out that we have a custom security
provider installed on our servers and when I disabled that the problem
disappeared.
/Tommy
On 2018-01-19 14:40, Tommy Stendahl wrote:
I have continu
I have continued the upgrade of the cluster using the default protocol
setting and after upgrading all nodes there were no problems switching
back to "TLSv1.2". But I will try to reproduce the problem using a ccm
cluster, I think that should be relatively easy, and when can try the
-Djavax.net
>
> We use Oracle jdk1.8.0_152 on all nodes and as I understand oracle use a
> dot in the protocol name (TLSv1.2) and I use the same protocol name and
> cipher names in the 3.0.14 nodes and the one I try to upgrade to 3.11.1.
>
I agree with Stefan's assessment and share his confusion. Would you be
We use Oracle jdk1.8.0_152 on all nodes and as I understand oracle use a
dot in the protocol name (TLSv1.2) and I use the same protocol name and
cipher names in the 3.0.14 nodes and the one I try to upgrade to 3.11.1.
On 2018-01-17 15:02, Georg Brandemann wrote:
If i remember correctly the pro
If i remember correctly the protocol names differ between some JRE vendors.
With IBM Java for instance the protocol name would be TLSv12 ( without . ).
Are you using the same JRE on all nodes and is the protocol name and cipher
names exactly the same on all nodes?
2018-01-17 14:51 GMT+01:00 Tomm
Thanks for your response.
I got it working by removing my protocol setting from the configuration
on the 3.11.1 node so it use the default protocol setting, I'm not sure
exactly how that change things so I need to investigate that. We don't
have any custom ssl settings that should affect this
Thanks for your response.
I removed the protocol setting from the server_encryption_options in the
3.11.1 node so it use the default value instead and now it works. I have
to analyse if this has any impact on my security requirements but at
least its working now.
/Tommy
On 2018-01-16 17:26
I think what this error indicates is that a client is trying to connect
using a SSLv2Hello handshake, while this protocol has been disabled on
the server side. Starting with the mentioned ticket, we use the JVM
default list of enabled protocols. What makes this issue a bit
confusing, is that starti
This looks like the post-POODLE commit:
https://issues.apache.org/jira/browse/CASSANDRA-10508
I think you might just set 'TLS' as in the example to use the JVM's
preferred TLS protocol version.
--
Michael
On 01/16/2018 08:13 AM, Tommy Stendahl wrote:
> Hi,
>
> I have problems upgrading a clust
Dan,
What partitioner are you using and did you just swap out the binary?
Going from 70GB to 200GB+ is extremely odd in any scenario.
Maybe Carlos Rolo has an idea about this issue. He did a ton of 1.2 cluster
upgrades.
As for the tombstones, its the stat for the last five minutes. You could
have
Nope, just ran out of disk space... So on 1.2.x I had 70GB used on a 200GB
disk and everything was great, with 2.0.x I'm now at 99% used and getting
exception while compacting about insufficient disk space. FML...
Dan Washusen
On Sun, Dec 31, 2017 at 6:47 AM, Dan Washusen wrote:
> Thanks for t
Thanks for the response Jeff. It wasn't snapshots but after running
upgradesstables on all nodes I started a repair and it seems like the file
sizes are reducing:
INFO [CompactionExecutor:1626] 2017-12-30 19:42:36,065 CompactionTask.java
(line 299) Compacted 2 sstables to
[/appdata/lib/cassandra/
1.2 to 2.0 was a long time ago for many of us, but I don’t recall anything that
should have doubled size other than perhaps temporarily during the sstable
rewrite or snapshots (which may? Be automatic on upgrade).
The bloom filters, sstable count, compression ratio in cfstats all look
similar,
, 2017 5:17 AM
To: user@cassandra.apache.org
Cc: Hannu Kröger
Subject: [EXTERNAL] Re: Upgrade using rebuild
Any specific reason why It doesn't work across major version ? a
On Fri, Dec 15, 2017 at 12:05 AM, Jon Haddad
mailto:j...@jonhaddad.com>> wrote:
Heh, hit send acciden
Any specific reason why It doesn't work across major version ? a
On Fri, Dec 15, 2017 at 12:05 AM, Jon Haddad wrote:
> Heh, hit send accidentally.
>
> You generally can’t run rebuild to upgrade, because it’s a streaming
> operation. Streaming isn’t supported between versions, although on 3.x
Thanks Jon.
On Fri, Dec 15, 2017 at 12:05 AM, Jon Haddad wrote:
> Heh, hit send accidentally.
>
> You generally can’t run rebuild to upgrade, because it’s a streaming
> operation. Streaming isn’t supported between versions, although on 3.x it
> might work.
>
>
> On Dec 14, 2017, at 11:01 AM, Jo
Heh, hit send accidentally.
You generally can’t run rebuild to upgrade, because it’s a streaming operation.
Streaming isn’t supported between versions, although on 3.x it might work.
> On Dec 14, 2017, at 11:01 AM, Jon Haddad wrote:
>
> no
>
>> On Dec 14, 2017, at 10:59 AM, Anshu Vajpayee >
no
> On Dec 14, 2017, at 10:59 AM, Anshu Vajpayee wrote:
>
> Thanks! I am aware with these steps.
>
> I m just thinking , is it possible to do the upgrade using nodetool rebuild
> like we rebuld new dc ?
>
> Has anyone tried - upgrade with nodetool rebuild ?
>
>
>
> On Thu, 14 Dec 2017 a
Thanks! I am aware with these steps.
I m just thinking , is it possible to do the upgrade using nodetool rebuild
like we rebuld new dc ?
Has anyone tried - upgrade with nodetool rebuild ?
On Thu, 14 Dec 2017 at 7:08 PM, Hannu Kröger wrote:
> If you want to do a version upgrade, you need to
If you want to do a version upgrade, you need to basically do follow node
by node:
0) stop repairs
1) make sure your sstables are at the latest version (nodetool
upgradesstables can do it)
2) stop cassandra
3) update cassandra software and update cassandra.yaml and cassandra-env.sh
files
4) start
NEWS.txt is the goto spot for upgrade instructions, caveats, etc.
Jon
> On Aug 22, 2017, at 2:46 PM, Chuck Reynolds wrote:
>
> Anyone?
>
> From: "Chuck (me) Reynolds"
> Reply-To: "user@cassandra.apache.org"
> Date: Tuesday, August 22, 2017 at 9:40 AM
> To: "user@cassandra.apache.org"
> Sub
Anyone?
From: "Chuck (me) Reynolds"
Reply-To: "user@cassandra.apache.org"
Date: Tuesday, August 22, 2017 at 9:40 AM
To: "user@cassandra.apache.org"
Subject: Upgrade requirements for upgrading from cassandra 2.1.x to 2.2.x
Where can I find requirements to upgrade from Cassandra 2.1.x to 2.2.x?
Jeff,
Thank you so much for your answer. If you say there are 2 very important
fixes in next release I believe we can wait couple of weeks.
Thanks!
On Fri, Jun 16, 2017 at 12:35 AM, Jeff Jirsa wrote:
>
>
> On 2017-06-14 07:05 (-0700), Riccardo Ferrari wrote:
> > Hi list,
> >
> > It's been a w
On 2017-06-14 07:05 (-0700), Riccardo Ferrari wrote:
> Hi list,
>
> It's been a while since I upgraded my C* to 3.0.6, nevertheless I would
> like to give TWCS a try (avaialble since 3.0.7).
>
> What happened to the upgrade documentation ? I was used to read some
> step-by-step procedure from
I installed 2.7 and updated PYTHONPATH, but it is still not finding the
newer version.
-- Jacob Shadix
On Tue, Apr 4, 2017 at 11:22 AM, Voytek Jarnot
wrote:
> Multiple versions of python can coexist, the cqlsh shell script will
> attempt to execute via a python2.7 executable if it finds one.
>
Hi Jacob,
if you use RHEL/Centos, this article in Datastax Help Center explains how
to solve the issue:
https://support.datastax.com/hc/en-us/articles/115000180726--No-appropriate-python-interpreter-found-when-running-cqlsh
Kind regards,
2017-04-04 17:22 GMT+02:00 Voytek Jarnot :
> Multiple ver
Multiple versions of python can coexist, the cqlsh shell script will
attempt to execute via a python2.7 executable if it finds one.
On Tue, Apr 4, 2017 at 9:49 AM, Jacob Shadix wrote:
> I've recently upgraded to 3.0.12 and unable to run CQLSH.
> No appropriate python interpreter found.
>
> The c
> If you do not feel ready for incremental repairs, just adding the '-full'
option to your 'nodetool repair' command should be enough to continue
repairing as you currently are once using 3.0.7.
This is not entirely true on 2.2+ after CASSANDRA-7586, since
anti-compaction is always executed after
1 - 100 of 267 matches
Mail list logo
