couple questions about commitlogs and the nodetool drain operator:
* in 0.6, after invoking a drain, the commitlog directory would be empty.
in 0.8, it seems to contain 2 files, a 44 byte .header file and 270 byte
.log file. do these indicate a fully drained commitlog?
* i have a couple node
hope this is not off topic?
we've been struggling following ostensible procedures for awhile now,
ready to pony up for some pro help (but not quite ready to pony up for
datastax). please contact me at svd at mylife dot com if you are
interested.
-scott
i recently finished a practice expansion of 4 nodes to 5 nodes, a series
of "nodetool move", "nodetool cleanup" and jmx gc steps. i found that in
some of the steps, disk usage actually grew to 2.5x the base data size on
one of the nodes. i'm using 0.6.4.
-scott
On Thu, 9 Dec 2010, Rustam Al
i followed the alternative approach for handling a failed node here:
http://wiki.apache.org/cassandra/Operations
i.e. bringing up a replacement node with the same ip, bootstrapping it
into the same token used by the failed node (using the InitialToken config
parameter), then doing a repair. a
On Mon, 16 Aug 2010, Scott Dworkis wrote:
i followed the alternative approach for handling a failed node here:
http://wiki.apache.org/cassandra/Operations
i.e. bringing up a replacement node with the same ip, bootstrapping it into
the same token used by the failed node (using the InitialTok
following the failure handling process described here:
http://wiki.apache.org/cassandra/Operations
i don't at the end seem to have all the data... i have half as much being
reported by nodetool ring as i started with. i'm guessing the replicas
are not being recovered. however if i take the e
in case the community is interested, my gmetric collector:
http://github.com/scottnotrobot/gmetric/tree/master/database/cassandra/
note i have only tested with a special csv mode of gmetric... you can
bypass this mode and use vanilla gmetric with --nocsv, but beware it will
generate over 100 f
