Oh, right: my plan didn't work, because schema changes aren't really
commitlog-ified. (So, commitlog replayed, but the schema didn't get
recreated to match its earlier state.)
Can you reproduce the old-fashioned way by sending the create + insert
commands, after nuking things?
On Mon, Aug 22, 20
0.8.4 seems to fail to load in the same way. When i deleted the data
directory, it appears to start up correctly, I see
INFO 23:30:44,067 JNA not found. Native methods will be disabled.
INFO 23:30:44,100 Loading settings from
file:/home/dave/apache-cassandra-0.8.4/conf/cassandra.yaml
INFO 23:
It's erroring out trying to load the schema itself, though, which
isn't supposed to happen.
On Mon, Aug 22, 2011 at 10:14 PM, Dave Brosius wrote:
> Sure i'll try that, but I'm pretty sure it was creating a column family
> without any column meta data (types), then, client.insert'ing a ByteBuffer
Sure i'll try that, but I'm pretty sure it was creating a column family
without any column meta data (types), then, client.insert'ing a
ByteBuffer that wasn't based on bytes from a String.getBytes call.
On 08/22/2011 11:09 AM, Jonathan Ellis wrote:
Yes, you can blow away both the data and co
Yes, you can blow away both the data and commitlog directories and
restart, but can you try these first to troubleshoot?
1. make a copy of the commitlog directory
2. downgrade to 0.8 with no other changes, to see if it's something on
the new read path
2a. if 0.8 starts up then we will fix the read
Greetings, I'm running head from source, and now when i try to start up
the database, i get the following exception which causes client
connection failures. I'm fine with blowing away the database, just
playing, but wanted to know if there is a safe way to do this.
Exception encountered during
