On Thu, Feb 1, 2018 at 9:23 AM, Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> On 1 Feb 2018 06:51, "kurt greaves" wrote:
>
> Would you be able to create a JIRA ticket for this? Not sure if this is
> still a problem in 3.0+ but worth creating a ticket to investigate. It'd be
> really
On 1 Feb 2018 06:51, "kurt greaves" wrote:
Would you be able to create a JIRA ticket for this? Not sure if this is
still a problem in 3.0+ but worth creating a ticket to investigate. It'd be
really helpful if you could try and reproduce on 3.0.15 or 3.11.1 to see if
it's an issue there as well.
Would you be able to create a JIRA ticket for this? Not sure if this is
still a problem in 3.0+ but worth creating a ticket to investigate. It'd be
really helpful if you could try and reproduce on 3.0.15 or 3.11.1 to see if
it's an issue there as well.
On Wed, Jan 24, 2018 at 10:40 AM, Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> Hello,
>
> In the process of upgrading our cluster from 2.1 to 2.2 we have triggered
> the SSTable rewriting process like this:
>
> $ nodetool upgradesstables -j 4 # concurrent_compactors=5
>
> Then if we
Hello,
In the process of upgrading our cluster from 2.1 to 2.2 we have triggered
the SSTable rewriting process like this:
$ nodetool upgradesstables -j 4 # concurrent_compactors=5
Then if we would immediately check the compactionstats, we see that 4
compactions of type 'Upgrade sstables' are ru