RE: [EXTERNAL] Re: Even after the drop table, the data actually was not erased.

...@gmail.com] Sent: Monday, January 15, 2018 1:19 PM To: user cassandra.apache.org Subject: [EXTERNAL] Re: Even after the drop table, the data actually was not erased. As you said, the auto_bootstrap setting was turned on. Well I was talking about the 'auto_snapshot' ;-). I understand t

Re: Even after the drop table, the data actually was not erased.

> > As you said, the auto_bootstrap setting was turned on. Well I was talking about the 'auto_snapshot' ;-). I understand that's what you meant to say. This command seems to apply only to one node. Can it be applied > cluster-wide? Or should I run this command on each node? Indeed, 'nodetool c

Re: Even after the drop table, the data actually was not erased.

Thank you for your response. As you said, the auto_bootstrap setting was turned on. The actual data was deleted with the 'nodetool clearsnapshot' command. This command seems to apply only to one node. Can it be applied cluster-wide? Or should I run this command on each node? > On 12 Jan 2018

Re: Even after the drop table, the data actually was not erased.

Hello, However, the actual size of the data directory did not decrease at all. > Disk Load monitored by JMX has been decreased. This sounds like 'auto_snapshot' is enabled. This option will trigger a snapshot before any table drop / truncate to prevent user mistakes mostly. Then the data is remo

Even after the drop table, the data actually was not erased.

hi everyone On the development server, I dropped all the tables and even keyspace dropped to change the table schema. Then I created the keyspace and the table. However, the actual size of the data directory did not decrease at all. Disk Load monitored by JMX has been decreased. After that,

Re: how to effectively drop table

OK! I'll drop keyspaces. Thanks 2016-11-24 19:14 GMT+08:00 Vladimir Yudovin : > Actually you shouldn't drop tables prior to dropping keyspace. Just drop > keyspace with all its tables. > > Best regards, Vladimir Yudovin, > *Winguzone - Cloud Cassandra Hosting* >

Re: how to effectively drop table

Actually you shouldn't drop tables prior to dropping keyspace. Just drop keyspace with all its tables. Best regards, Vladimir Yudovin, Winguzone - Cloud Cassandra Hosting On Thu, 24 Nov 2016 05:38:36 -0500joseph gao wrote Hi，Vladimir, I have

Re: how to effectively drop table

Hi，Vladimir, I have to do the whole stuff in 2 step. DROP whole keyspace works in step2. But in step 1, I have to drop 2000 tables。 All I could wait and skip step 1 and do all jobs in step 2. Anyway, thanks very much! 2016-11-24 16:25 GMT+08:00 Vladimir Yudovin : > Hi, > > Is DROP whole k

Re: how to effectively drop table

Hi, Is DROP whole keyspace an option? Best regards, Vladimir Yudovin, Winguzone - Cloud Cassandra Hosting On Thu, 24 Nov 2016 03:00:40 -0500joseph gao wrote Hi, all I've had a very bad system design before. This caused about 1 tables in

how to effectively drop table

Hi, all I've had a very bad system design before. This caused about 1 tables in my cassandra cluster, and the cluster is very unstable. Now I want to redesign the system, but it's so suffering to drop the former tables. Dropping a table may cost 30 seconds or even worse(170s) using cqlsh or

Re: DROP Table

Saladi > > -- > *From:* Sebastian Estevez > *To:* user@cassandra.apache.org; Saladi Naidu > *Sent:* Friday, July 10, 2015 5:25 PM > *Subject:* Re: DROP Table > > #1 The cause of this problem is a CREATE TABLE statement collision. Do > *not*

Re: DROP Table

erride the current file right? >> >> 3. Do we have to rename the directory name to remove CFID i.e. just >> column family name without CFID? After that, update the System table as >> well? >> >> >> Naidu Saladi >> >> --

Re: DROP Table

t; -- > *From:* Sebastian Estevez > *To:* user@cassandra.apache.org; Saladi Naidu > *Sent:* Friday, July 10, 2015 5:25 PM > *Subject:* Re: DROP Table > > #1 The cause of this problem is a CREATE TABLE statement collision. Do > *not* generate tab

Re: DROP Table

user@cassandra.apache.org; Saladi Naidu Sent: Friday, July 10, 2015 5:25 PM Subject: Re: DROP Table #1 The cause of this problem is a CREATE TABLE statement collision. Do not  generate tables dynamically from multiple clients, even with IF NOT EXISTS. First thing you need to do is fix your code so that

Re: DROP Table

#1 The cause of this problem is a CREATE TABLE statement collision. Do *not* generate tables dynamically from multiple clients, even with IF NOT EXISTS. First thing you need to do is fix your code so that this does not happen. Just create your tables manually from cqlsh allowing time for the schema

DROP Table

My understanding is that Cassandra File Structure follows below naming convention /cassandra/data/         Whereas our file structure is as below, each table has multiple names and when we drop tables and recreate these directories remain. Also when we dropped the table one node was down, whe

Re: DROP Table put Cassandra in an inconsistent state

On Fri, Jul 4, 2014 at 10:31 AM, Simon Chemouil wrote: > Hi, > > I just encountered a bug with 2.1-rc1 (didn't have the chance to update > to rc2 yet), and wondering if it's known or if I should report the issue > on JIRA. FWIW I think this issue might be related to what you are seeing: https://i

Re: DROP Table put Cassandra in an inconsistent state

On Fri, Jul 4, 2014 at 2:31 AM, Simon Chemouil wrote: > I just encountered a bug with 2.1-rc1 (didn't have the chance to update > to rc2 yet), and wondering if it's known or if I should report the issue > on JIRA. > For issues in pre-release versions of Cassandra, JIRA is almost certainly the ri

DROP Table put Cassandra in an inconsistent state

ropped (at least trough regular means, using CQL). Hope this helps! Cheers, Simon logs below Here's what happens when I try to drop the table or keyspace, or even create a table with the same name from cqlsh: cqlsh:hybrid> create table t2 (name INT PRIMARY KEY); cqlsh:hybrid> drop