cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Ortolani <>
Subject Re: Bootstrapping a node fails because of compactions not keeping up
Date Wed, 23 Aug 2017 11:17:08 GMT
Hi Kurt,

On Wed, Aug 23, 2017 at 11:32 AM, kurt greaves <> wrote:

> ‚Äč1) You mean restarting the node in the middle of the bootstrap with
>> join_ring=false? Would this option require me to issue a nodetool boostrap
>> resume, correct? I didn't know you could instruct the join via JMX. Would
>> it be the same of the nodetool boostrap command?
> write_survey is slightly different to join_ring. TBH I haven't used
> write_survey myself for this purpose, but I believe it should work. The
> code certainly indicates that it will bootstrap and stream, but just not
> join the ring until you trigger a joinRing with JMX. (You'll have to look
> up the specific JMX call to make, there is one somewhere...)

But if it also streams, it means I'd still be under-pressure if I am not
mistaken. I am under the assumption that the compactions are the by-product
of streaming too many SStables at the same time, and not because of my
current write load.

> 2) Yes, they are streamed into L0 as far as I can see (although they are
>> mainly L2/L3 on the existing nodes). I don't think I can do much about it
>> as long as I am using LCS, am I right?
>  Code seems to imply that it should always keep SSTable levels. Sounds
> like something is wrong if it is not :/.

I don't have the logs anymore (machine had other issues, replacing disks)
so I can't be sure of this. Definitely I remember a high volume of
"Bootstrapping - doing STCS in L0" messages, which alone do not imply
though that all sstables were streamed at L0, so I can't be sure of this. I
just noticed you were mentioning L1 tables too. Why would that affect the
disk footprint?


View raw message