Could you provide some of the log messages when the receiver ran out of disk space ? Sounds like it should be at ERROR level.
Thanks ----------------- Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com On 6 May 2011, at 09:16, Sameer Farooqui wrote: > Just wanted to update you guys that we turned on DEBUG level logging on the > decommissioned node and the node receiving the decommissioned node's range. > We did this by editing <cassandra-home>/conf/log4j-server.properties and > changing the log4j.rootLogger to DEBUG. > > We ran decommission again and saw the that the receiving node was running out > of disk space. The 184GB file was not able to fully stream to the receiving > node. > > We simply added more disk space to the receiving node and then decommission > ran successfully. > > Thanks for your help Aaron and also thanks for all those Cassandra articles > on your blog. We found them helpful. > > - Sameer > Accenture Technology Labs > > > On Thu, May 5, 2011 at 3:59 AM, aaron morton <aa...@thelastpickle.com> wrote: > Yes that was what I was trying to say. > > thanks > ----------------- > Aaron Morton > Freelance Cassandra Developer > @aaronmorton > http://www.thelastpickle.com > > On 5 May 2011, at 18:52, Tyler Hobbs wrote: > >> On Thu, May 5, 2011 at 1:21 AM, Peter Schuller <peter.schul...@infidyne.com> >> wrote: >> > It's no longer recommended to run nodetool compact regularly as it can mean >> > that some tombstones do not get to be purged for a very long time. >> >> I think this is a mis-typing; it used to be that major compactions >> were necessary to remove tombstones, but this is no longer the case in >> 0.7 so that the need for major compactions is significantly lessened >> or even eliminated. However, running major compactions won't cause >> tombstones *not* to be removed; it's just not required *in order* for >> them to be removed. >> >> I think he was suggesting that any tombstones *left* in the large sstable >> generated by the major compaction won't be removed for a long time because >> that sstable itself will not participate in any minor compactions for a long >> time. (In general, rows in that sstable will not be merged for a long time.) >> >> -- >> Tyler Hobbs >> Software Engineer, DataStax >> Maintainer of the pycassa Cassandra Python client library >> > >
