Severity: moderate
Affected versions:
- Apache Cassandra 4.0.0 through 4.0.15
- Apache Cassandra 4.1.0 through 4.1.7
- Apache Cassandra 5.0.0 through 5.0.2
Description:
Incorrect Authorization vulnerability in Apache Cassandra allowing users to
access a datacenter or IP/CIDR groups they should
Severity: moderate
Affected versions:
- Apache Cassandra 3.0.0 through 3.0.30
- Apache Cassandra 3.1.0 through 3.11.17
- Apache Cassandra 4.0.0 through 4.0.15
- Apache Cassandra 4.1.0 through 4.1.7
- Apache Cassandra 5.0.0 through 5.0.2
Description:
Privilege Defined With Unsafe Actions vulnera
Severity: moderate
Affected versions:
- Apache Cassandra 4.0.2 before 4.0.15
- Apache Cassandra 4.1.0 before 4.1.8
- Apache Cassandra 5.0-beta1 before 5.0.3
Description:
In Apache Cassandra it is possible for a local attacker without access
to the Apache Cassandra process or configuration file
Hi Manish,
My understanding from the links you shared is that only upgrading from 4.X
to 5.0 is supported. If you are in version 3.11.12 the standard
recommendation is to upgrade to 4.1.latest before going to 5.0.
This is not to say that upgrading from 3.11 to 5.0 does not work, it might
work but
Hi,
I would like to invite Cassandra contributors and enthusiasts to gather in
Denver, USA from October 7 to 10 for the ASF conference Community Over Code
(formerly known as ApacheCon).
There will be two days of Cassandra talks on Monday (10/07) and Tuesday
(10/08). You can check the event schedu
19 PM Paulo Motta wrote:
> Hi,
>
> I wanted to update that the Call for Presentations deadline was extended
> by two weeks to April 15th, 2024 for Community Over Code North America
> 2024. Find more information on this blog post:
> https://news.apache.org/foundation/entry/apa
Hi,
I wanted to update that the Call for Presentations deadline was extended by
two weeks to April 15th, 2024 for Community Over Code North America 2024.
Find more information on this blog post:
https://news.apache.org/foundation/entry/apache-software-foundation-opens-cfp-for-community-over-code-n
Hi,
I'd like to send a friendly reminder that the deadline for submissions to
Community Over Code North America 2024 ends in two
weeks on April 1st, 2024. This conference will be held in Denver, Colorado,
October 7-10, 2024.
We're looking for abstracts in the following areas:
* Customizing and t
Hi,
After a successful experience in ApacheCon 2022, the Cassandra track is
back to Community Over Code North America 2024 to be held in Denver,
Colorado, October 7-10, 2024.
I will be facilitating this track and I would like to request abstract
drafts in the following topics to be presented in t
I wanted to remind that the call for speakers for Community Over Code EU
2024 (formerly Apachecon EU) will be closing this Friday 2024/01/12
23:59:59 GMT.
If you reside in Europe/EMEA and have an interesting talk proposal about
using, deploying or modifying Apache Cassandra please see details belo
There will be a Cassandra track at Community Over Code Europe 2024
(formerly known as Apachecon EU) that will happen on Bratislava, Slovakia
on 3 Jun 2024.
If you have any talks proposals about using, deploying or modifying Apache
Cassandra please make a submission before 12 Jan 2024 to speak at a
This Cassandra Summit is going to be epic!
Looking forward to meet the Cassandra community in two weeks! 🤘👋
On Wed, 29 Nov 2023 at 18:26 Patrick McFadin wrote:
> Hi everyone,
>
> We are a couple of weeks away from Cassandra Summit. People get busy and
> forget to register or miss that there is e
Hi,
On the dev@ mailing list I proposed updating the default value of the
advanced property "disk_access_mode" to a more stable default for typical
workloads. See the discussion on [1] for details.
I wanted to check if anyone had experiences (good or bad) with overriding
this setting in the past,
Hello everyone,
The 2022 ASF Community Survey is looking to gather scientific data that
allows us to understand our community better, both in its demographic
composition, and also in collaboration styles and preferences. We want to
find areas where we can continue to do great work, and others whe
It think topology file is better for static clusters, while rackdc for
dynamic clusters where users can add/remove hosts without needing to update
the topology file on all hosts.
On Thu, 2 Jun 2022 at 09:13 Marc Hoppins wrote:
> Hi all,
>
> Why is RACKDC preferred for production than TOPOLOGY?
>
> It was my understanding that when the nodetool snapshot process finished,
the snapshot was done.
This is correct. But snapshots could be partially available when using
incremental_backups or snapshot_before_compaction option.
If the compression/upload process starts after nodetool snapshot fini
How does the backup process ensure the snapshot is taken before starting to
upload it ? A snapshot is only safe to use after the "manifest.json" file
is written.
I wonder if the snapshot is being compressed while the snapshot file is
still being created.
Em ter., 22 de mar. de 2022 às 14:17, Paul
Hi Sebastian,
I'm not aware of any reasoning behind this choice (happy to be corrected),
but I think it wouldn't hurt to have better default permissions.
Feel free to open a JIRA ticket to suggest this change on
https://issues.apache.org/jira/projects/CASSANDRA/summary
Em ter., 22 de mar. de 202
All these symptoms indicate a potential hotspot in this replica, which can
be caused by one or likely multiple "hot" partitions. Finding out which
particular partition(s) is responsible for this is tricky, but good
candidates are the ones mentioned in the log warning.
Ideally you should fix your d
Cross-posting announcement to user list
-- Forwarded message -
From: Benjamin Lerer
Date: Thu, 3 Mar 2022 at 08:41
Subject: New Apache Cassandra Group on LinkedIn
To:
Hi everybody,
We just created a new Apache Cassandra group on LinkedIn (
https://www.linkedin.com/groups/91594
> I can reproduce this with a huge load using dsbulk, but still can't
determine the cause of the problem.
Can you get a thread dump (jstack ) when the system freezes? This
might be helpful to determine the cause of the freeze.
Also, can you reproduce this in a simpler environment (ccm + dsbulk)?
Hi Attila,
Minor version upgrades are generally fine to do in-place, unless otherwise
specified on NEWS.txt <
https://github.com/apache/cassandra/blob/cassandra-4.0.1/NEWS.txt> for the
specific versions you're upgrading. Cassandra is designed with this goal in
mind, and potentially disruptive chan
Hi Bowen,
This seems like a bug to me, please kindly file an issue on
https://issues.apache.org/jira/projects/CASSANDRA/summary with the provided
reproduction steps.
Thanks,
Paulo
Em ter., 4 de mai. de 2021 às 18:22, Bowen Song escreveu:
> Hi all,
>
>
> I was using the cqlsh from Cassandra 4.
> I don't want to enable DEBUG logs as there are a lot of DiskBoundary
messages, which are very high in volume.
These messages shouldn't be very high volume as they only appear when there
are ring updates, schema changes or node startup. If this is not the case
please file a JIRA issue.
Em qua.,
.
Em qui., 3 de dez. de 2020 às 09:33, Paulo Motta
escreveu:
> I think this could've been caused by
> https://issues.apache.org/jira/browse/CASSANDRA-15690 which was
> introduced on 3.11.7 and removed an optimization that may cause a
> correctness issue when there are partition delet
I think this could've been caused by
https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced
on 3.11.7 and removed an optimization that may cause a correctness issue
when there are partition deletions. I'd suggest you to open an issue at
https://issues.apache.org/jira/projects/CA
Hi all,
I'd like to invite the user community to give feedback on the design
concepts below to a new website for the Apache Cassandra project.
Thanks,
Paulo
-- Forwarded message -
De: Melissa Logan
Date: qua., 30 de set. de 2020 às 16:43
Subject: Re: [DISCUSS] Updating the C* w
decommissioned node to the other cluster it is
> giving me an error that cluster_name is not matching however cluster name
> is correct as per new cluster.
> So until i issue assasinate , i am not able to move forward.
>
> On Thu, Sep 17, 2020 at 1:13 PM Paulo Motta
> wrote:
>
&g
After decommissioning the node remains in gossip for a period of 3 days (if
I recall correctly) and it will show up on describecluster during that
period, so this is expected behavior. This allows other nodes that
eventually were down when the node decommissioned to learn that this node
left the cl
These messages should go away when the decommission/removenode is complete.
Are you seeing them repeating for the same nodes after they've left or do
they eventually stop?
If not this is expected behavior but perhaps a bit too verbose if the
message is being printed more than once per node removal
> cassandra.yaml states that "Directories where Cassandra should store data on
> disk. Cassandra will spread data evenly across them, subject to the
> granularity of the configured compaction strategy.". I feel it is not correct
> anymore. Is it worth updating the doc?
In fact this changed aft
Are you using JBOD? A thread dump (jstack ) on the affected nodes
would probably help troubleshoot this.
2018-01-25 6:45 GMT-02:00 shini gupta :
> Hi,
>
>
> We have upgraded the system from Cassandra 2.1.16 to 3.11.1. After about
> 335M of data loading, repair with –pr and –full option was trigge
> This is also the case for full repairs, if I'm not mistaken. Assuming I'm not
> missing something here, that should mean that he shouldn't need to mark
> sstables as unrepaired?
That's right, but he mentioned that he is using reaper which uses
subrange repair if I'm not mistaken, which doesn't
> Assuming the situation is just "we accidentally ran incremental repair", you
> shouldn't have to do anything. It's not going to hurt anything
Once you run incremental repair, your data is permanently marked as
repaired, and is no longer compacted with new non-incrementally
repaired data. This c
In 4.0 anti-compaction is no longer run after full repairs, so we
should probably backport this behavior to 3.0, given there are known
limitations with incremental repair on 3.0 and non-incremental users
may want to run keep running full repairs without the additional cost
of anti-compaction.
Woul
This is address on 3.11.1 on CASSANDRA-13641. Workaround for now is
probably truncating system.prepared_statements before restart of node
as being done for now.
2017-07-25 11:12 GMT-05:00 Taylor Cressy :
> +1 bump.
>
> We are experiencing the same issue
>
> On Jul 25, 2017, at 08:02, Anshul Rathor
i-compaction to be run.
>
> Not sure since what version, but in 3.10 at least (I think its since 3.x
> started) full repair does do anti-compactions and marks sstables as
> repaired.
>
> On 23 June 2017 at 06:30, Paulo Motta wrote:
>>
>> > This attribute seems
> This attribute seems to be only modified when executing "nodetool repair
> [keyspace] [table]", but not when executing with other options like
> --in-local-dc or --pr.
This is correct behavior because this metric actually represent the
percentage of SSTables incrementally repaired - and ma
It's safe to truncate this table since it's just used to inspect repairs
for troubleshooting. You may also set a default TTL to avoid it from
growing unbounded (this is going to be done by default on CASSANDRA-12701).
2017-03-17 8:36 GMT-03:00 Gábor Auth :
> Hi,
>
> I've discovered a relative hug
> there are some nasty edge cases when you mix incremental repair and full
repair ( https://issues.apache.org/jira/browse/CASSANDRA-13153 )
mixing incremental and full repairs will just make that more likely to
happen, but although unlikely it's still possible for a similar condition
to happen eve
The objective of non-incremental primary-range repair is to avoid redoing
work, but with incremental repair anticompaction will segregate repaired
data so no extra work is done on the next repair.
You should run nodetool repair [ks] [table] in all nodes sequentially. The
more often you run, the sm
Fixed on https://issues.apache.org/jira/browse/CASSANDRA-12905 (still to be
released). If you're running repair of all keyspace or tables in a single
command, run each table separately and should improve things a bit.
2017-01-05 7:54 GMT-02:00 Robert Sicoie :
> Hi guys,
>
> While running repairs,
See CASSANDRA-11752 for 2.2+ histogram.
2016-12-17 21:13 GMT-02:00 Aleksandr Ivanov :
> Hi C* experts!
>
> I'm trying to understand over what time range C* latency metrics histogram
> is calculated.
> Several sources state that max is calculated from C* start, but on graphs
> I see that max laten
If you have an MV table It seems you're hitting
https://issues.apache.org/jira/browse/CASSANDRA-12905. I will bump it's
priority to critical since it can prevent or difficult bootstrap.
Did you try resuming bootstrap with "nodetool bootstrap resume" after the
failure? It may eventually succeed, si
This is not a problem per se, it's just the maximum number of concurrent
threads allowed in the validation pool which is Integer.MAX_VALUE, which
will limit the maximum number of simultaneous validations the node will
handle. It may be too big, but you probably will never reach anywhere close
to th
It's safe but since the replacement node will stream data from a single
replica per local range, it will potentially propagate any inconsistencies
from the replica it streams from, so it's recommended to run repair after a
replace to reduce entropy specially when replacing a node with the same IP
d
130:4091:face:0:13:0 shows
> "TOKENS: not present", on all live nodes. It means tokens are missing,
> right? What would cause this?
>
> Thanks.
> Dikang.
>
> On Fri, Nov 18, 2016 at 11:15 AM, Paulo Motta
> wrote:
>
>> What does nodetool gossipinfo shows for
What does nodetool gossipinfo shows for endpoint
/2401:db00:2130:4091:face:0:13:0 ? Does it contain the TOKENS attribute? If
it's missing, is it only missing on this node or other nodes as well?
2016-11-18 17:02 GMT-02:00 Dikang Gu :
> Hi, I encountered couple times that I could not replace a dow
This is an informative piece on (anti-entropy) repairs:
https://cassandra-zone.com/understanding-repairs/
2016-11-18 8:12 GMT-02:00 wxn...@zjqunshuo.com :
> Thanks Ben for the response. It's very helpfull and it's really what I
> want.
>
>
> *From:* Ben Dalling
> *Date:* 2016-11-18 18:07
> *To:*
For the record, there is an interesting use case of globo.com using
Cassandra to store video payload and stream live video at scale (in
particular, the FIFA World Cup + Olympics), but it's a pretty
non-conventional/advanced use case:
-
https://leandromoreira.com.br/2015/04/26/fifa-2014-world-cup-li
Haven't seen this before, but perhaps it's related to CASSANDRA-10433? This
is just a wild guess as it's in a related codepath, but maybe worth trying
out the patch available to see if it helps anything...
2016-10-28 15:03 GMT-02:00 Dikang Gu :
> We are seeing huge cpu regression when upgrading o
I had this problem before but can't remember the root cause, but I think it
was related to conflicting JVMs on the same machine. Can you check if you
have more than one JVM installed and try to define JAVA_HOME if it's not
defined?
Maybe this is related: https://github.com/rhuss/jolokia/issues/189
performing the anticompaction phase?
>
> Cheers,
> Stefano
>
> On Tue, Sep 27, 2016 at 4:09 PM, Stefano Ortolani
> wrote:
> > Didn't know about (2), and I actually have a time drift between the
> nodes.
> > Thanks a lot Paulo!
> >
> > Regards,
> >
There were a few streaming bugs fixed between 2.1.13 and 2.1.15 (see
CHANGES.txt for more details), so I'd recommend you to upgrade to 2.1.15 in
order to avoid having those.
2016-09-28 9:08 GMT-03:00 Alain RODRIGUEZ :
> Hi Anubhav,
>
>
>> I’m considering doing subrange repairs (https://github.com
> *at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:413)*
> *at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:245)*
> *at java.lang.Thread.run(Thread.java:745)*
>
> On Sep 27, 2016 11:
:
> @Paulo Motta
>
> Even we are facing Streaming timeout exceptions during 'nodetool rebuild'
> , I set streaming_socket_timeout_in_ms to 8640 (24 hours) as suggested
> in datastax blog - https://support.datastax.com/h
> c/en-us/articles/206502913-FAQ-How-to-reduc
There are a couple of things that could be happening here:
- There will be time differences between when nodes participating repair
flush, so in write-heavy tables there will always be minor differences
during validation, and those could be accentuated by low resolution merkle
trees, which will aff
Hello Zhiyan,
Replying to the mailing list since this could help others. I'm not sure
what that could be, it's generally related to some kind of corruption,
perhaps CASSANDRA-10791. Although the message is similar to #10971, that is
restricted to streaming so it's a different issue here. Was this
s why '-full'
> option was added. You did the hardest part in noticing this change and
> start wondering about it.
>
> C*heers,
> ---
> Alain Rodriguez - @arodream - al...@thelastpickle.com
> France
>
> The Last Pickle - Apache Cassandra Consulting
> http://w
on by just marking SSTables as being repaired (which is fast),
> but the rest of the nodes will still have to perform anticompaction as they
> won't share all of its token ranges. Right ?
>
> Cheers,
>
> Alex
>
> Le lun. 12 sept. 2016 à 13:56, Paulo Motta a
> écrit :
This seems like a bug, it seems we always bind the outgoing socket to the
private/listen address. Would you mind opening a JIRA and posting the link
here?
Thanks
2016-09-12 3:35 GMT-03:00 Amir Dafny-Man :
> Hi,
>
>
>
> I followed the docs (http://docs.datastax.com/en/cassandra/3.x/cassandra/
> c
> Are there equivalent JIRAs for the TODOs somewhere?
Not that I know of, but I think you can create a github pull request for
punctual doc updates and AFAIK a jira ticket will be automatically created
from it.
Alternatively, feel free to open a JIRA meta-ticket with subtasks for doc
TODOs and pu
> I truncate a table lcs, Then I inserted one line and I used nodetool
flush to have all the sstables. Using a RF 3 I ran a repair -inc directly
and I observed that the value of Reaired At was equal 0.
Were you able to troubleshoot this? The value of repairedAt should be
mutated even when there is
>> An extract of this conversation should definitely be posted somewhere.
>> Read a lot but never learnt all these bits...
>>
>> On Fri, Aug 26, 2016 at 2:53 PM, Paulo Motta
>> wrote:
>>
>>> > I must admit that I fail to understand currently how runn
Migration procedure is no longer required for incremental repair as of
2.1.4 since CASSANDRA-8004, which was the reason why the migration
procedure was required for LCS before. The migration procedure is only
useful now to skip validation on already repaired sstables in the first
incremental repair
3
> 127.0.0.5
>
> > ccm node1 nodetool getendpoints replication_test sample bif
>
> 127.0.0.3
> 127.0.0.5
> 127.0.0.1
>
> > ccm node1 nodetool getendpoints replication_test sample biz
>
> 127.0.0.2
> 127.0.0.3
> 127.0.0.5
>
> On Fri, Sep 2, 2016 at 9
Forwarding to the user@cassandra.apache.org list as this list is specific
for cassandra-development, not general cassandra questions.
Can you check the repository you built the snapshot from contains the
commit 01d5fa8acf05973074482eda497677c161a311ac?
Is java 1.8.0_101 on your $env:PATH ? Can yo
com/questions/82414/do-you-have-to-run-nodetool-repair-on-every-node.
>
> Thanks again.
>
> George
>
> On Thu, Sep 1, 2016 at 10:22 AM, Paulo Motta
> wrote:
>
>> https://issues.apache.org/jira/browse/CASSANDRA-7450
>>
>> 2016-09-01 13:11 GMT-03:00 Li, Guangxing :
https://issues.apache.org/jira/browse/CASSANDRA-7450
2016-09-01 13:11 GMT-03:00 Li, Guangxing :
> Hi,
>
> I have a cluster running 2.0.9 with 2 data centers. I noticed that
> 'nodetool repair -pr keyspace cf' runs very slow (OpsCenter shows that the
> node's data size is 39 GB and the largest SST
clarifying!
>
>
> On Fri, Aug 26, 2016 at 2:14 PM, Paulo Motta
> wrote:
>
>> > What is the underlying reason?
>>
>> Basically to minimize the amount of anti-compaction needed, since with
>> RF=3 you'd need to perform anti-compaction 3 times in a par
't know incremental repairs were not compatible with -pr
> What is the underlying reason?
>
> Regards,
> Stefano
>
>
> On Fri, Aug 26, 2016 at 1:25 AM, Paulo Motta
> wrote:
>
>> 1. Migration procedure is no longer necessary after CASSANDRA-8004, and
>> since
1. Migration procedure is no longer necessary after CASSANDRA-8004, and
since you never ran repair before this would not make any difference
anyway, so just run repair and by default (CASSANDRA-7250) this will
already be incremental.
2. Incremental repair is not supported with -pr, -local or -st/-e
on a node? My traffic would still fail.
>
> I want that at least nodes in my local DC should contact at each other on
> private IP. I thought preferred IP is for that purpose so focussing on
> fixing the null value of preferred IPs.
>
>
> Thanks
> Anuj
>
>
> On Sun, 21 A
See CASSANDRA-9748, I think it might be related.
2016-08-20 15:20 GMT-03:00 Anuj Wadehra :
> Hi,
>
> We use multiple interfaces in multi DC setup.Broadcast address is public
> IP while listen address is private IP.
>
> I dont understand why prefeerred IP in peers table is null for all rows.
>
> T
ables or not flagged ?
>
> By the way, I suppose the repair flag don't break sstable file
> immutability, so I wonder how it is stored.
>
> --
> Jérôme Mainaud
> jer...@mainaud.com
>
> 2016-08-19 15:02 GMT+02:00 Paulo Motta :
>
>> Running repair with -local fl
Running repair with -local flag does not mark sstables as repaired, since
you can't guarantee data in other DCs are repaired. In order to support
incremental repair, you need to run a full repair without the -local flag,
and then in the next time you run repair, previously repaired sstables are
ski
What version are you in? This seems like a typical case were there was a
problem with streaming (hanging, etc), do you have access to the logs?
Maybe look for streaming errors? Typically streaming errors are related to
timeouts, so you should review your cassandra
streaming_socket_timeout_in_ms and
-pr option ( which i suppose we should to
> prevent duplicate checks) in 2.0 then if we run the repair on all nodes in
> a single DC then it should be sufficient and we should not need to run it
> on all nodes across DC's ?
>
>
>
> On Wed, Aug 10, 2016 at 5:01 PM, Paulo M
Another thing to note is that according to NEWS.txt upgrade from 2.1.x is
only supported from version 2.1.9, so if this is not an effect of that I'm
actually surprised upgrade from 2.1.2 worked without any issues.
2016-08-10 15:48 GMT-03:00 Tyler Hobbs :
> That just means that a client/driver dis
thing
else wrong perhaps you need to increase your capacity. What version are you
in?
2016-08-10 8:21 GMT-03:00 Stefano Ortolani :
> Not yet. Right now I have it set at 16.
> Would halving it more or less double the repair time?
>
> On Tue, Aug 9, 2016 at 7:58 PM, Paulo Motta
> w
On 2.0 repair -pr option is not supported together with -local, -hosts or
-dc, since it assumes you need to repair all nodes in all DCs and it will
throw and error if you try to run with nodetool, so perhaps there's
something wrong with range_repair options parsing.
On 2.1 it was added support to
Anticompaction throttling can be done by setting the usual
compaction_throughput_mb_per_sec knob on cassandra.yaml or via nodetool
setcompactionthroughput. Did you try lowering that and checking if that
improves the dropped mutations?
2016-08-09 13:32 GMT-03:00 Stefano Ortolani :
> Hi all,
>
> I
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
(ConnectionHandler.java:257)
> ~[apache-cassandra-2.1.14.jar:2.1.14]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
>
> We have this error with at least 5 more nodes in the same log. But the
> error doesn't say that much
>
>
> Saludos
>
> Jean Carlo
>
> "
[na:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
>
> I al looking through the changes files to see if it is a bug fixed in the
> 2.1.15
It seems you have a streaming error, look for ERROR statement in the
streaming classes before that which may give you a more specific root
cause. In any case, I'd suggest you to upgrade to 2.1.15 as there were a
couple of streaming fixes on this version that might help.
2016-08-05 11:15 GMT-03:00
8df87657-c39b-405a-ba54-d60b577c1429 1d
> --
> --
> ip-10-4-43-65
> Datacenter: us-east
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Toke
This looks somewhat related to CASSANDRA-9630. What is the C* version?
Can you check with netstats if other nodes keep connections with the
stopped node in the CLOSE_WAIT state? And also if the problem disappears if
you run nodetool disablegossip before stopping the node?
2016-07-26 16:54 GMT-03:
Were you able to troubleshoot this yet? Private IPs for listen_address,
public IP for broadcast_address, and prefer_local=true on
cassandra-rackdc.properties should be sufficient to make nodes in the same
DC communicate over private address, so something must be going on there.
Can you check in yo
1. Not necessarily data corruption, but it seems compaction is trying to
write data in the wrong order most likely due to a temporary race
condition/bug a la #9935, but since the compaction fails your original data
is probably safe (you can try running scrub to verify/fix corruptions).
2. This is p
You could also be hitting CASSANDRA-11739, which was fixed on 3.0.7 and
could potentially cause OOMs for long-running repairs.
2016-06-20 13:26 GMT-03:00 Robert Stupp :
> One possibility might be CASSANDRA-11206 (Support large partitions on the
> 3.0 sstable format), which reduces heap usage for
Increasing the number of threads alone won't help, because you need to add
connectionsPerHost-awareness to StreamPlan.requestRanges (otherwise only a
single connection per host is created) similar to what was done to
StreamPlan.transferFiles by CASSANDRA-3668, but maybe bit trickier. There's
an ope
For rebuild, replace and -Dcassandra.consistent.rangemovement=false in
general we currently pick the closest replica (as indicated by the Snitch)
which has the range, what will often map to the same node due to the
dynamic snitch, specially when N=RF. This is good for picking a node in the
same DC
I'm afraid raising streaming_socket_timeout_in_ms won't help much in this
case because the incoming connection on the source node is timing out on
the network layer, and streaming_socket_timeout_in_ms controls the socket
timeout in the app layer and throws SocketTimeoutException (not
java.io.IOExce
114
> StreamResultFuture.java:207 - [Stream
> #74c57bc0-231a-11e6-a698-1b05ac77baf9] Stream failed
>
> > Streaming does not seem to be resumed again from this node. Shall I just
> kill again the entire rebuild process?
>
> On Thu, May 26, 2016 at 12:17 AM, Paulo Motta
age.java:51)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:250)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_79]
>
> On W
> Workaround is to set to a larger streaming_socket_timeout_in_ms **on the
source node**., the new default will be 8640ms (1 day).
2016-05-25 17:23 GMT-03:00 Paulo Motta :
> Was there any other ERROR preceding this on this node (in particular the
> last few lines of [STREAM-IN-/172.
r.java:331)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_79]
>
> On Wed, May 25, 2016 at 8:49 PM, Paulo Motta
> wrote:
>
>> This is the log of the destination/rebuilding node, you need to check
>> what is the erro
amMessage.java:44)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:351)
> [apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessa
The stack trace from the rebuild command not show the root cause of the
rebuild stream error. Can you check the system.log for ERROR logs during
streaming and paste here?
1 - 100 of 176 matches
Mail list logo
