Sounds good. I'll open a ticket. As far as the workaround goes I use: (a)Flush on the node, (b) copy the database files to backup location.
I tested the backup files in my 3-node cluster (RF=3). (a).Took one node down(simulated crash. Ip, name key range stays the same). (b) Erased all keyspace folders and commit log. (c)Copied application related backup files. (d) Started the node. (e) Ran repair. Thanks, Stephan On Tue, Mar 22, 2011 at 4:40 PM, aaron morton <aa...@thelastpickle.com>wrote: > AFAIK upgrade from 0.6.2 to 0.6.12 should be a straight forward rolling > restart. Do check the changes.txt file first and if you have a test env test > it there. (The large gap in versions makes me a little nervous). > > If you feel it's reproducible (even sometimes) can you create a jira ticket > ? https://issues.apache.org/jira/browse/CASSANDRA > > Windows gets less loving than *nix so any help is appreciated. > > Thanks > Aaron > > > > On 23 Mar 2011, at 06:48, s p wrote: > > Thanks. The problem is intermittent meaning we have separate CA cluster > environments: In some cases there is no problem running a snapshot followed > by a later clear snapshot (or for that matter physical delete of the > snapshot file). > When I stop Cassandra the snapshot file can be deleted. As soon as > Cassandra is started the file is locked. > > While testing the above I monitored things with sysinternals (Handle, > ProcessExplorer, ProcMon). None of them show any open file handles/locks. > > Am I missing something? I see you suggestion going to 0.6.12. Can the > existing cluster (0.6.2) be upgraded node by node? > > -S > > On Mon, Mar 21, 2011 at 11:45 PM, aaron morton <aa...@thelastpickle.com>wrote: > >> There have been some issues to with deleting files on windows, cannot find >> a reference to it happening for snapshots. >> >> If you restart the node can you delete the snapshot? >> >> Longer term can you upgrade to 0.6.12 and let us know if it happens again? >> Any fix will be against that version. >> >> Hope that helps. >> Aaron >> >> >> On 22 Mar 2011, at 08:11, s p wrote: >> >> > I'm running 3-way CA cluster (0.62 ) on a windows 2008 (jre 1.6.24) >> 64-bit. Things are running fine except when trying to remove old snaphsot >> files. When running clearsnapshot I get an error msg like below. I can't >> remove any daily snapshot files. When trying to delete the actual snapshot >> file os cmd file I get "access denied. File used by another process". Seems >> CA or JRE is sitting on file? >> > >> > Feedback much appreciated. >> > >> > >> > C:\Cassandra\ >> > Exception in thread "main" java.io.IOException: Failed to delete >> c:\cassandra\da >> > >> ta\data\ks_SnapshotTest\snapshots\1300731301822-ks_SnapshotTest\cf_SnapshotTest-135-Data.db >> > at >> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.ja >> > va:47) >> > at >> org.apache.cassandra.io.util.FileUtils.deleteDir(FileUtils.java:189) >> > at >> org.apache.cassandra.io.util.FileUtils.deleteDir(FileUtils.java:184) >> > at >> org.apache.cassandra.io.util.FileUtils.deleteDir(FileUtils.java:184) >> > at org.apache.cassandra.db.Table.clearSnapshot(Table.java:274) >> > at >> org.apache.cassandra.service.StorageService.clearSnapshot(StorageServ >> > ice.java:1023) >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown >> Source) >> > at java.lang.reflect.Method.invoke(Unknown Source) >> > at >> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown So >> > urce) >> > at >> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown So >> > urce) >> > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown >> Source) >> > at com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source) >> > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source) >> > at >> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown >> > Source) >> > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) >> > at >> javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Sou >> > rce) >> > at >> javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Sour >> > ce) >> > at >> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run >> > (Unknown Source) >> > at >> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(U >> > nknown Source) >> > at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown >> Source) >> > at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown >> Source) >> > at java.lang.reflect.Method.invoke(Unknown Source) >> > at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) >> > at sun.rmi.transport.Transport$1.run(Unknown Source) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at sun.rmi.transport.Transport.serviceCall(Unknown Source) >> > at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown >> Source) >> > at >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Sou >> > rce) >> > at >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Sour >> > ce) >> > at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source >> > ) >> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >> Source) >> > at java.lang.Thread.run(Unknown Source) >> > >> > C:\Cassandra\bin> >> > >> > >> > >> > >> > >> >> > >
