You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Jai Bheemsen Rao Dhanwada <ja...@gmail.com> on 2017/11/30 00:05:23 UTC

Schema version mismatch with 3.0.8 and 3.0.14

Hello,



I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I am
adding a new node with 3.0.14 version to 3.0.8. cluster and I see the
schema disagreement between the nodes and the new node doesn't stream any
data.

I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559,
does this mean, I will not be able to add nodes with the higher version
than 3.0.13?

here is what I see in the nodetool describecluster output

$ nodetool describecluster
Cluster Information:
    Name: production
    Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
    Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
    Schema versions:
        45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2,
192.168.1.3, 192.168.1.4]

        c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]

Any work around to mitigate this?

Re: Schema version mismatch with 3.0.8 and 3.0.14

Posted by Jon Haddad <jo...@jonhaddad.com>.
Generally speaking, I would never advise someone to add nodes to a cluster using a different version than the rest of the cluster.  

> On Dec 1, 2017, at 11:58 AM, Jai Bheemsen Rao Dhanwada <ja...@gmail.com> wrote:
> 
> Thanks Jeff,
> 
> I did some more testing on this version upgrade and here is brief summary incase if someone runs into the same issue.
> 
> Basically, we cannot add new nodes with 3.0.14 or higher version to the cluster with 3.0.8 version of cassandra (haven't tested with 3.0.13) and below are the two options available
> 
> 1. Rolling upgrade all the nodes in the cluster to 3.0.14 and add new nodes with the same version 3.0.14
> OR
> 2. use the flag "-Dcassandra.force_3_0_protocol_version=true" to join the nodes with higher version.
> 
> On Thu, Nov 30, 2017 at 9:45 AM, Jeff Jirsa <jjirsa@gmail.com <ma...@gmail.com>> wrote:
> I guess I didn’t realize you were adding and upgrading s
> at the same time
> 
> Do one or the other first (either add the new node at the old version, or upgrade to the new version and then add the new node), or use the two step process described in 13004
> 
> -- 
> Jeff Jirsa
> 
> 
> On Nov 30, 2017, at 9:40 AM, Jai Bheemsen Rao Dhanwada <jaibheemsen@gmail.com <ma...@gmail.com>> wrote:
> 
>> Hello Jeff,
>> 
>> I tried with 3.0.15 as well and I see the same issue.
>> 
>> Here are the steps I followed.
>> 
>> 1. I have a 3 node C* cluster with 3.0.8 version
>> 2. Added a new node (4th) node with 3.0.15 version of cassandra
>> 3. New node joins the cluster but it is creates it's own schema and don't bootstrap any keyspace or column families from the cluster.
>> 
>> in the logs I could see the below WARN message.
>> 
>> OutboundTcpConnection.java:488 - Seed gossip version is 10; will not connect with that version
>> 
>> so we cannot join a new node with the higher minor version to the cluster?
>> 
>> On Wed, Nov 29, 2017 at 5:16 PM, Jeff Jirsa <jjirsa@gmail.com <ma...@gmail.com>> wrote:
>> Yes, going to 3.0.14 or 3.0.15 should work correctly
>> 
>> 3.0.15 will have important bug fixes not in 3.0.14
>> 
>> 
>> -- 
>> Jeff Jirsa
>> 
>> 
>> On Nov 29, 2017, at 4:52 PM, Jai Bheemsen Rao Dhanwada <jaibheemsen@gmail.com <ma...@gmail.com>> wrote:
>> 
>>> Thanks Jeff,
>>> 
>>> You mean if I upgrade from 3.0.8 -> 3.0.15 it should work without any issues?
>>> 
>>> On Wed, Nov 29, 2017 at 4:21 PM, Jeff Jirsa <jjirsa@gmail.com <ma...@gmail.com>> wrote:
>>> This is because in 3.0.14, we had to bump the internode messaging version to fix a nasty bug (it's something we almost never do in minor versions, but it was necessary here), and schema changes won't cross internode messaging versions.
>>> 
>>> You can continue upgrading, and when new nodes reach 3.0.14 they'll get the new schema versions. Until they all match, schema changes won't propagate properly.
>>> 
>>> If you REALLY need schema changes to propagate during the upgrade, you should read the notes on CASSANDRA-13004 and Alex's summary here https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6 <https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6> 
>>> 
>>> But really, you should just upgrade to 3.0.15 and not do any schema changes until the upgrade is complete (and be aware that having 2 schema versions during the upgrade is normal and expected).
>>> 
>>> - Jeff
>>> 
>>> 
>>> On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada <jaibheemsen@gmail.com <ma...@gmail.com>> wrote:
>>> Hello,
>>> 
>>> 
>>> 
>>> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the schema disagreement between the nodes and the new node doesn't stream any data.
>>> 
>>> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559 <https://issues.apache.org/jira/browse/CASSANDRA-13559>, does this mean, I will not be able to add nodes with the higher version than 3.0.13?
>>> 
>>> here is what I see in the nodetool describecluster output
>>> 
>>> $ nodetool describecluster
>>> Cluster Information:
>>>     Name: production
>>>     Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>>>     Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>>>     Schema versions:
>>>         45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
>>> 
>>>         c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
>>> Any work around to mitigate this?
>>> 
>>> 
>>> 
>> 
> 


Re: Schema version mismatch with 3.0.8 and 3.0.14

Posted by Jai Bheemsen Rao Dhanwada <ja...@gmail.com>.
Thanks Jeff,

I did some more testing on this version upgrade and here is brief summary
incase if someone runs into the same issue.

Basically, we cannot add new nodes with 3.0.14 or higher version to the
cluster with 3.0.8 version of cassandra (haven't tested with 3.0.13) and
below are the two options available

1. Rolling upgrade all the nodes in the cluster to 3.0.14 and add new nodes
with the same version 3.0.14
OR
2. use the flag "-Dcassandra.force_3_0_protocol_version=true" to join the
nodes with higher version.

On Thu, Nov 30, 2017 at 9:45 AM, Jeff Jirsa <jj...@gmail.com> wrote:

> I guess I didn’t realize you were adding and upgrading s
> at the same time
>
> Do one or the other first (either add the new node at the old version, or
> upgrade to the new version and then add the new node), or use the two step
> process described in 13004
>
> --
> Jeff Jirsa
>
>
> On Nov 30, 2017, at 9:40 AM, Jai Bheemsen Rao Dhanwada <
> jaibheemsen@gmail.com> wrote:
>
> Hello Jeff,
>
> I tried with 3.0.15 as well and I see the same issue.
>
> Here are the steps I followed.
>
> 1. I have a 3 node C* cluster with 3.0.8 version
> 2. Added a new node (4th) node with 3.0.15 version of cassandra
> 3. New node joins the cluster but it is creates it's own schema and don't
> bootstrap any keyspace or column families from the cluster.
>
> in the logs I could see the below WARN message.
>
> OutboundTcpConnection.java:488 - Seed gossip version is 10; will not
> connect with that version
>
> so we cannot join a new node with the higher minor version to the cluster?
>
> On Wed, Nov 29, 2017 at 5:16 PM, Jeff Jirsa <jj...@gmail.com> wrote:
>
>> Yes, going to 3.0.14 or 3.0.15 should work correctly
>>
>> 3.0.15 will have important bug fixes not in 3.0.14
>>
>>
>> --
>> Jeff Jirsa
>>
>>
>> On Nov 29, 2017, at 4:52 PM, Jai Bheemsen Rao Dhanwada <
>> jaibheemsen@gmail.com> wrote:
>>
>> Thanks Jeff,
>>
>> You mean if I upgrade from 3.0.8 -> 3.0.15 it should work without any
>> issues?
>>
>> On Wed, Nov 29, 2017 at 4:21 PM, Jeff Jirsa <jj...@gmail.com> wrote:
>>
>>> This is because in 3.0.14, we had to bump the internode
>>> messaging version to fix a nasty bug (it's something we almost never do in
>>> minor versions, but it was necessary here), and schema changes won't cross
>>> internode messaging versions.
>>>
>>> You can continue upgrading, and when new nodes reach 3.0.14 they'll get
>>> the new schema versions. Until they all match, schema changes won't
>>> propagate properly.
>>>
>>> If you REALLY need schema changes to propagate during the upgrade, you
>>> should read the notes on CASSANDRA-13004 and Alex's summary here
>>> https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6
>>>
>>> But really, you should just upgrade to 3.0.15 and not do any schema
>>> changes until the upgrade is complete (and be aware that having 2 schema
>>> versions during the upgrade is normal and expected).
>>>
>>> - Jeff
>>>
>>>
>>> On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada <
>>> jaibheemsen@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14.
>>>> I am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the
>>>> schema disagreement between the nodes and the new node doesn't stream any
>>>> data.
>>>>
>>>> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559,
>>>> does this mean, I will not be able to add nodes with the higher version
>>>> than 3.0.13?
>>>>
>>>> here is what I see in the nodetool describecluster output
>>>>
>>>> $ nodetool describecluster
>>>> Cluster Information:
>>>>     Name: production
>>>>     Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>>>>     Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>>>>     Schema versions:
>>>>         45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
>>>>
>>>>         c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
>>>>
>>>> Any work around to mitigate this?
>>>>
>>>
>>>
>>
>

Re: Schema version mismatch with 3.0.8 and 3.0.14

Posted by Jeff Jirsa <jj...@gmail.com>.
I guess I didn’t realize you were adding and upgrading s
at the same time

Do one or the other first (either add the new node at the old version, or upgrade to the new version and then add the new node), or use the two step process described in 13004

-- 
Jeff Jirsa


> On Nov 30, 2017, at 9:40 AM, Jai Bheemsen Rao Dhanwada <ja...@gmail.com> wrote:
> 
> Hello Jeff,
> 
> I tried with 3.0.15 as well and I see the same issue.
> 
> Here are the steps I followed.
> 
> 1. I have a 3 node C* cluster with 3.0.8 version
> 2. Added a new node (4th) node with 3.0.15 version of cassandra
> 3. New node joins the cluster but it is creates it's own schema and don't bootstrap any keyspace or column families from the cluster.
> 
> in the logs I could see the below WARN message.
> 
> OutboundTcpConnection.java:488 - Seed gossip version is 10; will not connect with that version
> 
> so we cannot join a new node with the higher minor version to the cluster?
> 
>> On Wed, Nov 29, 2017 at 5:16 PM, Jeff Jirsa <jj...@gmail.com> wrote:
>> Yes, going to 3.0.14 or 3.0.15 should work correctly
>> 
>> 3.0.15 will have important bug fixes not in 3.0.14
>> 
>> 
>> -- 
>> Jeff Jirsa
>> 
>> 
>>> On Nov 29, 2017, at 4:52 PM, Jai Bheemsen Rao Dhanwada <ja...@gmail.com> wrote:
>>> 
>>> Thanks Jeff,
>>> 
>>> You mean if I upgrade from 3.0.8 -> 3.0.15 it should work without any issues?
>>> 
>>>> On Wed, Nov 29, 2017 at 4:21 PM, Jeff Jirsa <jj...@gmail.com> wrote:
>>>> This is because in 3.0.14, we had to bump the internode messaging version to fix a nasty bug (it's something we almost never do in minor versions, but it was necessary here), and schema changes won't cross internode messaging versions.
>>>> 
>>>> You can continue upgrading, and when new nodes reach 3.0.14 they'll get the new schema versions. Until they all match, schema changes won't propagate properly.
>>>> 
>>>> If you REALLY need schema changes to propagate during the upgrade, you should read the notes on CASSANDRA-13004 and Alex's summary here https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6 
>>>> 
>>>> But really, you should just upgrade to 3.0.15 and not do any schema changes until the upgrade is complete (and be aware that having 2 schema versions during the upgrade is normal and expected).
>>>> 
>>>> - Jeff
>>>> 
>>>> 
>>>>> On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada <ja...@gmail.com> wrote:
>>>>> Hello,
>>>>> 
>>>>> 
>>>>> 
>>>>> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the schema disagreement between the nodes and the new node doesn't stream any data.
>>>>> 
>>>>> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559, does this mean, I will not be able to add nodes with the higher version than 3.0.13?
>>>>> 
>>>>> here is what I see in the nodetool describecluster output
>>>>> 
>>>>> $ nodetool describecluster
>>>>> Cluster Information:
>>>>>     Name: production
>>>>>     Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>>>>>     Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>>>>>     Schema versions:
>>>>>         45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
>>>>> 
>>>>>         c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
>>>>> Any work around to mitigate this?
>>>>> 
>>>> 
>>> 
> 

Re: Schema version mismatch with 3.0.8 and 3.0.14

Posted by Jai Bheemsen Rao Dhanwada <ja...@gmail.com>.
Hello Jeff,

I tried with 3.0.15 as well and I see the same issue.

Here are the steps I followed.

1. I have a 3 node C* cluster with 3.0.8 version
2. Added a new node (4th) node with 3.0.15 version of cassandra
3. New node joins the cluster but it is creates it's own schema and don't
bootstrap any keyspace or column families from the cluster.

in the logs I could see the below WARN message.

OutboundTcpConnection.java:488 - Seed gossip version is 10; will not
connect with that version

so we cannot join a new node with the higher minor version to the cluster?

On Wed, Nov 29, 2017 at 5:16 PM, Jeff Jirsa <jj...@gmail.com> wrote:

> Yes, going to 3.0.14 or 3.0.15 should work correctly
>
> 3.0.15 will have important bug fixes not in 3.0.14
>
>
> --
> Jeff Jirsa
>
>
> On Nov 29, 2017, at 4:52 PM, Jai Bheemsen Rao Dhanwada <
> jaibheemsen@gmail.com> wrote:
>
> Thanks Jeff,
>
> You mean if I upgrade from 3.0.8 -> 3.0.15 it should work without any
> issues?
>
> On Wed, Nov 29, 2017 at 4:21 PM, Jeff Jirsa <jj...@gmail.com> wrote:
>
>> This is because in 3.0.14, we had to bump the internode messaging version
>> to fix a nasty bug (it's something we almost never do in minor versions,
>> but it was necessary here), and schema changes won't cross internode
>> messaging versions.
>>
>> You can continue upgrading, and when new nodes reach 3.0.14 they'll get
>> the new schema versions. Until they all match, schema changes won't
>> propagate properly.
>>
>> If you REALLY need schema changes to propagate during the upgrade, you
>> should read the notes on CASSANDRA-13004 and Alex's summary here
>> https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6
>>
>> But really, you should just upgrade to 3.0.15 and not do any schema
>> changes until the upgrade is complete (and be aware that having 2 schema
>> versions during the upgrade is normal and expected).
>>
>> - Jeff
>>
>>
>> On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada <
>> jaibheemsen@gmail.com> wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I
>>> am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the
>>> schema disagreement between the nodes and the new node doesn't stream any
>>> data.
>>>
>>> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559,
>>> does this mean, I will not be able to add nodes with the higher version
>>> than 3.0.13?
>>>
>>> here is what I see in the nodetool describecluster output
>>>
>>> $ nodetool describecluster
>>> Cluster Information:
>>>     Name: production
>>>     Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>>>     Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>>>     Schema versions:
>>>         45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
>>>
>>>         c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
>>>
>>> Any work around to mitigate this?
>>>
>>
>>
>

Re: Schema version mismatch with 3.0.8 and 3.0.14

Posted by Jeff Jirsa <jj...@gmail.com>.
Yes, going to 3.0.14 or 3.0.15 should work correctly

3.0.15 will have important bug fixes not in 3.0.14


-- 
Jeff Jirsa


> On Nov 29, 2017, at 4:52 PM, Jai Bheemsen Rao Dhanwada <ja...@gmail.com> wrote:
> 
> Thanks Jeff,
> 
> You mean if I upgrade from 3.0.8 -> 3.0.15 it should work without any issues?
> 
>> On Wed, Nov 29, 2017 at 4:21 PM, Jeff Jirsa <jj...@gmail.com> wrote:
>> This is because in 3.0.14, we had to bump the internode messaging version to fix a nasty bug (it's something we almost never do in minor versions, but it was necessary here), and schema changes won't cross internode messaging versions.
>> 
>> You can continue upgrading, and when new nodes reach 3.0.14 they'll get the new schema versions. Until they all match, schema changes won't propagate properly.
>> 
>> If you REALLY need schema changes to propagate during the upgrade, you should read the notes on CASSANDRA-13004 and Alex's summary here https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6 
>> 
>> But really, you should just upgrade to 3.0.15 and not do any schema changes until the upgrade is complete (and be aware that having 2 schema versions during the upgrade is normal and expected).
>> 
>> - Jeff
>> 
>> 
>>> On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada <ja...@gmail.com> wrote:
>>> Hello,
>>> 
>>> 
>>> 
>>> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the schema disagreement between the nodes and the new node doesn't stream any data.
>>> 
>>> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559, does this mean, I will not be able to add nodes with the higher version than 3.0.13?
>>> 
>>> here is what I see in the nodetool describecluster output
>>> 
>>> $ nodetool describecluster
>>> Cluster Information:
>>>     Name: production
>>>     Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>>>     Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>>>     Schema versions:
>>>         45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
>>> 
>>>         c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
>>> Any work around to mitigate this?
>>> 
>> 
> 

Re: Schema version mismatch with 3.0.8 and 3.0.14

Posted by Jai Bheemsen Rao Dhanwada <ja...@gmail.com>.
Thanks Jeff,

You mean if I upgrade from 3.0.8 -> 3.0.15 it should work without any
issues?

On Wed, Nov 29, 2017 at 4:21 PM, Jeff Jirsa <jj...@gmail.com> wrote:

> This is because in 3.0.14, we had to bump the internode messaging version
> to fix a nasty bug (it's something we almost never do in minor versions,
> but it was necessary here), and schema changes won't cross internode
> messaging versions.
>
> You can continue upgrading, and when new nodes reach 3.0.14 they'll get
> the new schema versions. Until they all match, schema changes won't
> propagate properly.
>
> If you REALLY need schema changes to propagate during the upgrade, you
> should read the notes on CASSANDRA-13004 and Alex's summary here
> https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6
>
> But really, you should just upgrade to 3.0.15 and not do any schema
> changes until the upgrade is complete (and be aware that having 2 schema
> versions during the upgrade is normal and expected).
>
> - Jeff
>
>
> On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada <
> jaibheemsen@gmail.com> wrote:
>
>> Hello,
>>
>>
>>
>> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I
>> am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the
>> schema disagreement between the nodes and the new node doesn't stream any
>> data.
>>
>> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559,
>> does this mean, I will not be able to add nodes with the higher version
>> than 3.0.13?
>>
>> here is what I see in the nodetool describecluster output
>>
>> $ nodetool describecluster
>> Cluster Information:
>>     Name: production
>>     Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>>     Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>>     Schema versions:
>>         45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
>>
>>         c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
>>
>> Any work around to mitigate this?
>>
>
>

Re: Schema version mismatch with 3.0.8 and 3.0.14

Posted by Jeff Jirsa <jj...@gmail.com>.
This is because in 3.0.14, we had to bump the internode messaging version
to fix a nasty bug (it's something we almost never do in minor versions,
but it was necessary here), and schema changes won't cross internode
messaging versions.

You can continue upgrading, and when new nodes reach 3.0.14 they'll get the
new schema versions. Until they all match, schema changes won't propagate
properly.

If you REALLY need schema changes to propagate during the upgrade, you
should read the notes on CASSANDRA-13004 and Alex's summary here
https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6

But really, you should just upgrade to 3.0.15 and not do any schema changes
until the upgrade is complete (and be aware that having 2 schema versions
during the upgrade is normal and expected).

- Jeff


On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada <
jaibheemsen@gmail.com> wrote:

> Hello,
>
>
>
> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I
> am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the
> schema disagreement between the nodes and the new node doesn't stream any
> data.
>
> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559,
> does this mean, I will not be able to add nodes with the higher version
> than 3.0.13?
>
> here is what I see in the nodetool describecluster output
>
> $ nodetool describecluster
> Cluster Information:
>     Name: production
>     Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>     Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>     Schema versions:
>         45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
>
>         c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
>
> Any work around to mitigate this?
>