I am running 2.0.6 and I use /etc/init.d/cassandra start / stop . Also before
stopping I do :
nodetool disablegossip
nodetool disablethrift
nodetool drain
after that /etc/init.d/cassandra stop
On Monday, March 24, 2014 9:48 PM, Robert Coli rc...@eventbrite.com wrote:
On Mon, Mar 24, 2014 at
On Tue, Mar 25, 2014 at 5:36 AM, Batranut Bogdan batra...@yahoo.com wrote:
I am running 2.0.6 and I use /etc/init.d/cassandra start / stop . Also
before stopping I do :
nodetool disablegossip
nodetool disablethrift
nodetool drain
after that /etc/init.d/cassandra stop
This seems
Note that drain stops gossip and thrift anyway, so they are redundant.
On 25 March 2014 18:30, Robert Coli rc...@eventbrite.com wrote:
On Tue, Mar 25, 2014 at 5:36 AM, Batranut Bogdan batra...@yahoo.comwrote:
I am running 2.0.6 and I use /etc/init.d/cassandra start / stop . Also
before
On Tue, Mar 25, 2014 at 11:34 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
Note that drain stops gossip and thrift anyway, so they are redundant.
While we're noting implementation details... none of these functions
necessarily stop writes to your node, which is probably what
Hi,
On 25/03/14 19:30, Robert Coli wrote:
On Tue, Mar 25, 2014 at 5:36 AM, Batranut Bogdan batra...@yahoo.com
mailto:batra...@yahoo.com wrote:
I am running 2.0.6 and I use /etc/init.d/cassandra start / stop . Also
before stopping I do :
nodetool disablegossip
nodetool
I believe that no matter how I stop cassandra, I should not be missing data.
Even if compaction is in progress. As far as I can tell during compaction cassa
reads from some files and creates a new temp file. Here I believe that it
stores the info and after the new file is complete it should
On Tue, Mar 25, 2014 at 1:55 PM, Batranut Bogdan batra...@yahoo.com wrote:
I believe that no matter how I stop cassandra, I should not be missing
data. Even if compaction is in progress.
Well, excepting that what you describe is impossible if you crash
cassandra (kill -9, etc.), I agree. It's
What message would be on the log, or not on the log, what would you be
grep-ing for?
Also, why were you interested in startup procedure? Is there some best
practices: for that which could impact this?
On Tue, Mar 25, 2014 at 2:55 PM, Robert Coli rc...@eventbrite.com wrote:
On Tue, Mar 25,
On Tue, Mar 25, 2014 at 3:24 PM, James Rothering jrother...@codojo.mewrote:
What message would be on the log, or not on the log, what would you be
grep-ing for?
You'd be looking for the broken SSTable to appear in either a
MemtableFlusher line or a compaction line.
Also, why were you
I thought someone asked what was your startup/shutdown procedure, and I
didn't see how startup could impact it. Maybe I mis-rememberd.
On Tue, Mar 25, 2014 at 3:36 PM, Robert Coli rc...@eventbrite.com wrote:
On Tue, Mar 25, 2014 at 3:24 PM, James Rothering jrother...@codojo.mewrote:
What
Well grepping the logs for a file resulted in this:
During startup that file was opened OK.
During runtime the compactionexecutor tried to compact more files that included
this one but threw and exception for another one that is first in that list. So
I do not have more info. In one particular
Hello all,
I am reposting a question about missing files on one of the nodes of my cluster.
After I first saw that I was missing a ...-Data.db file, I decomissioned the
node, deleted the data and added it back into the cluster. Now I see again that
I am missing some files.
Do you have an ideea
On Mon, Mar 24, 2014 at 9:41 AM, Batranut Bogdan batra...@yahoo.com wrote:
I am reposting a question about missing files on one of the nodes of my
cluster.
After I first saw that I was missing a ...-Data.db file, I decomissioned
the node, deleted the data and added it back into the cluster.
13 matches
Mail list logo
