You should not run a truncate until the whole ring is reporting
"Up/Normal." If there is a lot of flapping and it's a critical situation,
disable hinted handoff as well (and you may want to move
phi_convict_threshold up to 16 as well temporarily).
Stopping the compaction process temporarily on ea
Nate, how does this get around the issue? I'm guessing that just extends
the timeout, but if I had a server failure such that the server was down
for a couple hours, truncate would still have issues?
On Sat, May 23, 2015 at 5:46 PM, Nate McCall wrote:
> >
> > Truncate would have been the tool
Totally agree with this.
From: Ken Hancock [mailto:ken.hanc...@schange.com]
Sent: 22 May 2015 17:10
To: user@cassandra.apache.org
Subject: Re: Drop/Create table with same CF Name
This issue really needs to be strongly highlighted in the documentation.
Imagine someone noticing similarities
>
> Truncate would have been the tool of choice, however my understanding is
truncate fails unless all nodes are up and running which makes it a
non-workable choice since we can't determine when failures will occur.
>
You can get around this via:
- in cassandra.yaml, turning up "truncate_request_t
gt;
>
>
>
>
> *From:* Sebastian Estevez [mailto:sebastian.este...@datastax.com]
> *Sent:* 22 May 2015 14:46
>
> *To:* user@cassandra.apache.org
> *Subject:* Re: Drop/Create table with same CF Name
>
>
>
> I’m aware of issues where recreating key spaces can cause i
lto:ken.hanc...@schange.com>]
Sent: 21 May 2015 17:13
To: user@cassandra.apache.org<mailto:user@cassandra.apache.org>
Subject: Re: Drop/Create table with same CF Name
Thanks Mark (though that article doesn't appear publicly accessible for others).
Truncate would have been the tool of cho
;
>
>
> *From:* Ken Hancock [mailto:ken.hanc...@schange.com]
> *Sent:* 21 May 2015 17:13
> *To:* user@cassandra.apache.org
> *Subject:* Re: Drop/Create table with same CF Name
>
>
>
> Thanks Mark (though that article doesn't appear publicly accessible for
> othe
nt:* 21 May 2015 17:13
> *To:* user@cassandra.apache.org
> *Subject:* Re: Drop/Create table with same CF Name
>
>
>
> Thanks Mark (though that article doesn't appear publicly accessible for
> others).
>
> Truncate would have been the tool of choice, however my understanding is
&g
: user@cassandra.apache.org
Subject: Re: Drop/Create table with same CF Name
Thanks Mark (though that article doesn't appear publicly accessible for others).
Truncate would have been the tool of choice, however my understanding is
truncate fails unless all nodes are up and running which makes it a
Thanks Mark (though that article doesn't appear publicly accessible for
others).
Truncate would have been the tool of choice, however my understanding is
truncate fails unless all nodes are up and running which makes it a
non-workable choice since we can't determine when failures will occur.
Ken
Yes, it's a known issue. For more information on the topic see this support
post from DataStax:
https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1
Mark
On 21 May 2015 at 15:31, Ken Hancock wrote:
>
> We've been running
We've been running into the reused key cache issue (CASSANDRA-5202) with
dropping and recreating the same table in Cassandra 1.2.18 so we've been
testing with key caches disabled which does not seem to solve the issue.
In the latest logs it seems that old SSTables metadata gets read after the
table
12 matches
Mail list logo
