(REMINDER: the problem is that I cannot run ALTER on any CF - it seems
to work [schema number changes, no error occurs etc.], but no params are
updated.)
Hi Aaron (let me turn directly to you, as you were the only one who
replied my previous mails ;-) ),
Today we've added new CF and I notice
W dniu 26.04.2013 03:45, aaron morton pisze:
You can drop the hints via JMX and stopping the node and deleting the SSTables.
Thanks for advice :-) It's +/- what I did. I've paused hints delivery
first and then I upgraded whole cluster to C* with CASSANDRA-5179 patch
applied, removing the SSTa
You can drop the hints via JMX and stopping the node and deleting the SSTables.
Cheers
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 25/04/2013, at 12:27 AM, Michal Michalski wrote:
> Not really sure if it has something
Not really sure if it has something to do with the schema problems, but
I think the fact that node was down caused us to hit
https://issues.apache.org/jira/browse/CASSANDRA-5179 (a bit different
output on sender's side, but looks similar in general) - after checking
logs with debug level TRACE
That sounds horrible.
The log messages seem fine to me. It's handling eventually updating the
secondary indexes.
Good luck.
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 23/04/2013, at 6:34 PM, Michal Michalski wrote
A little update:
OK, after ~8 hours of GC madness and compacting node B (the one on which
keyspace has disappeared) works fine. No issues noticed so far.
Node A was started with larger heap and after I turned debugging on I
can see it does this:
DEBUG [MutationStage:110] 2013-04-23 06:23:44
Missing keyspace has reappeared on node B after restart, but it seems to
behave like node A. It starts, GC goes wild, I can see this:
INFO [ScheduledTasks:1] 2013-04-22 15:20:52,701 GCInspector.java (line
119) GC for ParNew: 646 ms for 1 collections, 6314013024 used; max is
8506048512
INFO [
W dniu 21.04.2013 22:17, aaron morton pisze:
This is a tricky one to diagnose remotely. I could try using nodetool
resetlocalschema on each node, it's just wild guess incase there is something
odd one one node.
I've run it on one node (let's call it A) and it finished without any
problems. T
>> [default@production] describe Users;
show schema; is the cli equivalent of describe in cqlsh.
There was a schema related issue in 1.1 CASSANDRA-4561 that was fixed.
This is a tricky one to diagnose remotely. I could try using nodetool
resetlocalschema on each node, it's just wild guess incas
It seems we can't update schemas at all. I tried to change
read_repair_chance and it looks the same. However, in this case I'm 99%
sure that some of the CFs I tried to update were NOT updated using CQL
*ever* - only CLI. Not good...
But, as I mentioned before - we did the same on test cluster
Hi Aaron,
Was the schema created with CQL or the CLI ?
It was created using Pycassa and - as far as I know - it was managed
only by CLI.
> (It's not a good idea to manage one with the other)
Yes, I know - I only tried using CQL after I realized that CLI is not
working, as I had to make it
e.com
On 19/04/2013, at 12:39 AM, Michal Michalski wrote:
> As stated in topic, I'm unable to drop secondary index either by using cli or
> cqlsh. In both cases it looks like to command is processed properly (some
> uuid shows up in cli, no output in cqlsh), I can see in logs that
As stated in topic, I'm unable to drop secondary index either by using
cli or cqlsh. In both cases it looks like to command is processed
properly (some uuid shows up in cli, no output in cqlsh), I can see in
logs that schema is going to be updated (index name and type are set to
null) and
13 matches
Mail list logo
