Re: Commitlog replay makes dropped and recreated keyspace and column family rows reappear

2013-12-23 Thread Aaron Morton
Aaron Morton > New Zealand > @aaronmorton > > Co-Founder & Principal Consultant > Apache Cassandra Consulting > http://www.thelastpickle.com > > > > From: Desimpel, Ignace > Sent: dinsdag 3 december 2013 14:45 > To: user@cassandra.apache.org > Subject: C

FW: Commitlog replay makes dropped and recreated keyspace and column family rows reappear

2013-12-18 Thread Desimpel, Ignace
-- Aaron Morton New Zealand @aaronmorton Co-Founder & Principal Consultant Apache Cassandra Consulting http://www.thelastpickle.com From: Desimpel, Ignace Sent: dinsdag 3 december 2013 14:45 To: user@cassandra.apache.org Subject: Commitlog replay makes dropped and recreated key

Re: Commitlog replay makes dropped and recreated keyspace and column family rows reappear

2013-12-08 Thread Aaron Morton
Do you have the logs from after the restart ? Did it include a "Drop Keyspace…” INFO level message ? Cheers - Aaron Morton New Zealand @aaronmorton Co-Founder & Principal Consultant Apache Cassandra Consulting http://www.thelastpickle.com On 4/12/2013, at 2:44 am, Desimpel, I

Commitlog replay makes dropped and recreated keyspace and column family rows reappear

2013-12-03 Thread Desimpel, Ignace
Hi, I have the impression that there is an issue with dropping a keyspace and then recreating the keyspace (and column families), combined with a restart of the database My test goes as follows: Create keyspace K and column families C. Insert rows X0 column family C0 Query for X0 : found rows

Re: commitlog replay extremely slow?

2011-10-18 Thread Yang
wrote: > I updated to 71ba6998b504966690e099c03e04f9876dc1060e  on github 1.0.0 > branch HEAD, > > now the new code seems to be very slow in commitlog replay, it takes > 20minutes to recover about 500MB of commit logs, while > previously this takes roughly 1--2 minutes. >

commitlog replay extremely slow?

2011-10-18 Thread Yang
I updated to 71ba6998b504966690e099c03e04f9876dc1060e on github 1.0.0 branch HEAD, now the new code seems to be very slow in commitlog replay, it takes 20minutes to recover about 500MB of commit logs, while previously this takes roughly 1--2 minutes. is the official 1.0.0 release built on

Re: commitlog replay missing data

2011-07-13 Thread Peter Schuller
> # wait for a bit until no one is sending it writes anymore More accurately, until all other nodes have realized it's down (nodetool ring on each respective host). -- / Peter Schuller (@scode on twitter)

Re: commitlog replay missing data

2011-07-13 Thread Peter Schuller
> What are the other ways to stop Cassandra? nodetool disablegossip nodetool disablethrift # wait for a bit until no one is sending it writes anymore nodetool flush # only relevant if in periodic mode # then kill it > What's the difference between batch vs periodic? Search for "batch" on http://

Re: commitlog replay missing data

2011-07-13 Thread mcasandra
Peter Schuller wrote: > >> Recently upgraded to 0.8.1 and noticed what seems to be missing data >> after a >> commitlog replay on a single-node cluster. I start the node, insert a >> bunch >> of stuff (~600MB), stop it, and restart it. There are log messages >

Re: commitlog replay missing data

2011-07-13 Thread Peter Schuller
> Recently upgraded to 0.8.1 and noticed what seems to be missing data after a > commitlog replay on a single-node cluster. I start the node, insert a bunch > of stuff (~600MB), stop it, and restart it. There are log messages If you stop by a kill, make sure you use batched commitlog s

Re: commitlog replay missing data

2011-07-13 Thread Aaron Morton
orton http://www.thelastpickle.com On 12/07/2011, at 3:28 PM, Jeffrey Wang wrote: > Hey all, > > > > Recently upgraded to 0.8.1 and noticed what seems to be missing data after a > commitlog replay on a single-node cluster. I start the node, insert a bunch > of stuff (~

commitlog replay missing data

2011-07-11 Thread Jeffrey Wang
Hey all, Recently upgraded to 0.8.1 and noticed what seems to be missing data after a commitlog replay on a single-node cluster. I start the node, insert a bunch of stuff (~600MB), stop it, and restart it. There are log messages pertaining to the commitlog replay and no errors, but some of the

Re: CommitLog replay

2011-06-21 Thread aaron morton
how long the default flush expiry period is? > > Cheers, > Steve > > -Original Message- > From: sc...@scode.org [mailto:sc...@scode.org] On Behalf Of Peter Schuller > Sent: Tuesday, June 21, 2011 9:13 AM > To: user@cassandra.apache.org > Subject: Re: CommitLog replay &

RE: CommitLog replay

2011-06-21 Thread Stephen Pope
nd how long the default flush expiry period is? Cheers, Steve -Original Message- From: sc...@scode.org [mailto:sc...@scode.org] On Behalf Of Peter Schuller Sent: Tuesday, June 21, 2011 9:13 AM To: user@cassandra.apache.org Subject: Re: CommitLog replay > I’ve got a single node deploy

Re: CommitLog replay

2011-06-21 Thread Peter Schuller
> I’ve got a single node deployment of 0.8 set up on my windows box. When I > insert a bunch of data into it, the commitlogs directory doesn’t clear upon > completion (should it?). It is expected that commit logs are retained for a while, and that there is reply going on when restarting a node. Th

CommitLog replay

2011-06-21 Thread Stephen Pope
Hi there. This is my first message to the mailing list, so let me know if I'm doing it wrong. :) I've got a single node deployment of 0.8 set up on my windows box. When I insert a bunch of data into it, the commitlogs directory doesn't clear upon completion (should it?). As a result, when I sto