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

2018-01-17 Thread Durity, Sean R
...@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.

2018-01-15 Thread Alain RODRIGUEZ
> > 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.

2018-01-14 Thread Eunsu Kim
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.

2018-01-12 Thread Alain RODRIGUEZ
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.

2018-01-11 Thread Eunsu Kim
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,