Hi,
On Tue, May 1, 2018 at 10:27 PM Gábor Auth wrote:
> One or two years ago I've tried the CDC feature but switched off... maybe
> is it a side effect of switched off CDC? How can I fix it? :)
>
Okay, I've worked out. Updated the schema of the affected keyspaces on the
new nodes with 'cdc=fals
Hi,
On Tue, May 1, 2018 at 7:40 PM Gábor Auth wrote:
> What can I do? Any suggestion? :(
>
Okay, I've diffed the good and the bad system_scheme tables. The only
difference is the `cdc` field in three keyspaces (in `tables` and `views`):
- the value of `cdc` field on the good node is `False`
- t
Hi,
On Mon, Apr 30, 2018 at 11:11 PM Gábor Auth wrote:
> On Mon, Apr 30, 2018 at 11:03 PM Ali Hubail
> wrote:
>
>> What steps have you performed to add the new DC? Have you tried to follow
>> certain procedures like this?
>>
>> https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/ops
Hi,
On Mon, Apr 30, 2018 at 11:03 PM Ali Hubail
wrote:
> What steps have you performed to add the new DC? Have you tried to follow
> certain procedures like this?
>
> https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsAddDCToCluster.html
>
Yes, exactly. :/
Bye,
Gábor Auth
"user@cassandra.apache.org" ,
cc
Subject
Re: Schema disagreement
Hi,
On Mon, Apr 30, 2018 at 11:39 AM Gábor Auth wrote:
've just tried to add a new DC and new node to my cluster (3 DCs and 10
nodes) and the new node has a different schema version:
Is it normal? Node is marked dow
Hi,
On Mon, Apr 30, 2018 at 11:39 AM Gábor Auth wrote:
> 've just tried to add a new DC and new node to my cluster (3 DCs and 10
> nodes) and the new node has a different schema version:
>
Is it normal? Node is marked down but doing a repair successfully?
WARN [MigrationStage:1] 2018-04-30 20
Hi Michael,
Did you ever get an answer on this? I'm curious to hear for future
reference.
Thanks,
Jens
On Monday, June 20, 2016, Michael Fong
wrote:
> Hi,
>
>
>
> We have recently encountered several schema disagreement issue while
> upgrading Cassandra. In one of the cases, the 2-node cluster
I too have noticed that after doing “nodetool flush” (or “nodetool drain”), the
commit logs are still there. I think they’re NEW (empty) commit logs, but I may
be wrong. Anyone know?
Don
From: Gaurav Sehgal [mailto:gsehg...@gmail.com]
Sent: Monday, May 12, 2014 12:31 PM
To: user@cassandra.apach
On Tue, May 13, 2014 at 5:11 PM, Donald Smith <
donald.sm...@audiencescience.com> wrote:
> I too have noticed that after doing “nodetool flush” (or “nodetool
> drain”), the commit logs are still there. I think they’re NEW (empty)
> commit logs, but I may be wrong. Anyone know?
>
Assuming they ar
Hey Gaurav,
You should consider moving to 2.0.7 which fixes a bunch of these schema
disagreement problems. You could also play around with nodetool
resetlocalschema on the nodes that are behind, but be careful with that
one. I'd go with 2.0.7 first for sure.
Thanks,
Vince.
On Mon, May 12, 2
Hi Gaurav, a schema versioning bug was fixed in 2.0.7.
Best wishes, Duncan.
On 12/05/14 21:31, Gaurav Sehgal wrote:
We have recently started seeing a lot of Schema Disagreement errors. We are
using Cassandra 2.0.6 with Oracle Java 1.7. I went through the Cassandra FAQ and
followed the below ste
Upgrade to 2.0.7 fixed this for me.
You can also try 'nodetool resetlocalschema' on disagreeing nodes. This
worked temporarily for me in 2.0.6.
ml
On Mon, May 12, 2014 at 3:31 PM, Gaurav Sehgal wrote:
> We have recently started seeing a lot of Schema Disagreement errors. We
> are using Cassan
Thanks Rob. Let me add one thing in case someone else finds this thread -
Restarting the nodes did not in and of itself get the schema disagreement
resolved. We had to run the ALTER TABLE command individually on each of the
disagreeing nodes once they came back up.
On Tuesday, November 26, 20
On Mon, Nov 25, 2013 at 6:42 PM, Josh Dzielak wrote:
> Recently we had a strange thing happen. Altering schema (gc_grace_seconds)
> for a column family resulted in a schema disagreement. 3/4 of nodes got it,
> 1/4 didn't. There was no partition at the time, nor was there multiple
> schema updates
Thanks, this is exactly it. We'd like to do a rolling upgrade - this is a
production cluster - so I guess we'll upgrade 1.0.6 -> 1.0.11 -> 1.1.4,
then.
/Martin
On Thu, Sep 6, 2012 at 2:35 AM, Omid Aladini wrote:
> Do you see exceptions like "java.lang.UnsupportedOperationException:
> Not a time
Do you see exceptions like "java.lang.UnsupportedOperationException:
Not a time-based UUID" in log files of nodes running 1.0.6 and 1.0.9?
Then it's probably due to [1] explained here [2] -- In this case you
either have to upgrade all nodes to 1.1.4 or if you prefer keeping a
mixed-version cluster,
I would try nodetool resetlocalschema.
On 12-09-05 07:08 AM, Martin Koch wrote:
Hi list
We have a 5-node Cassandra cluster with a single 1.0.9 installation
and four 1.0.6 installations.
We have tried installing 1.1.4 on one of the 1.0.6 nodes (following
the instructions on http://www.datas
So I was able to get the schema agreeing on the two bad nodes, but I don't
particularly like the way that I did it. One at a time, I shut them down,
removed Schema* and Migration*, then copied over Schema* from another
working node. They then started up with the correct schema. Did I do
somethin
Looks like a bug, patch is here
https://issues.apache.org/jira/browse/CASSANDRA-3391
Until it is fixed avoid using CompositeType in the key_validator_class and blow
away the Schema and Migrations SSTables.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thel
Thanks Aaron.
On Aug 2, 2011, at 3:04 AM, aaron morton wrote:
> Hang on, using brain now.
>
> That is triggering a small bug in the code see
> https://issues.apache.org/jira/browse/CASSANDRA-2984
>
> For not just remove the column meta data.
>
> Cheers
>
> -
> Aaron Morton
>
Thanks Jonathan.
On Aug 2, 2011, at 8:28 PM, Jonathan Ellis wrote:
> Have you seen http://wiki.apache.org/cassandra/FAQ#schema_disagreement ?
>
> On Tue, Aug 2, 2011 at 10:25 PM, Dikang Gu wrote:
>> I also encounter the schema disagreement in my 0.8.1 cluster today…
>>
>> The disagreement occ
It means the node you ran the command against could not contact node
192.168.1.25 it's probably down.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 3 Aug 2011, at 14:03, Dikang Gu wrote:
> I followed the instructions in the FA
I followed the instructions in the FAQ, but got the following when "describe
cluster;"
Snitch: org.apache.cassandra.locator.SimpleSnitch
Partitioner: org.apache.cassandra.dht.RandomPartitioner
Schema versions:
dd73c740-bd84-11e0--98dab94442fb: [192.168.1.28, 192.168.1.9, 192.168.1.27]
UNREAC
Have you seen http://wiki.apache.org/cassandra/FAQ#schema_disagreement ?
On Tue, Aug 2, 2011 at 10:25 PM, Dikang Gu wrote:
> I also encounter the schema disagreement in my 0.8.1 cluster today…
>
> The disagreement occurs when I create a column family using the hector api,
> and I found the follow
I also encounter the schema disagreement in my 0.8.1 cluster today…
The disagreement occurs when I create a column family using the hector api, and
I found the following errors in my cassandra/system.log
ERROR [pool-2-thread-99] 2011-08-03 11:21:18,051 Cassandra.java (line 3378)
Internal error
Hang on, using brain now.
That is triggering a small bug in the code see
https://issues.apache.org/jira/browse/CASSANDRA-2984
For not just remove the column meta data.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 2 Aug 2011
What do you see when you run describe cluster; in the cassandra-cli ? Whats the
exact error you get and is there anything in the server side logs ?
Have you added other CF's before adding this one ? Did the schema agree before
starting this statement?
I ran the statement below on the current tr
I thought the schema disagree problem was already solved in 0.8.1...
On possible solution is to decommission the disagree node and rejoin it.
On Tue, Aug 2, 2011 at 8:01 AM, Yi Yang wrote:
> Dear all,
>
> I'm always meeting mp with schema disagree problems while trying to create
> a column fam
28 matches
Mail list logo
