Hi,
I woud like to know how people are doing rolling upgrade of Casandra clustes
when there is a change in native protocol version say from 2.1 to 3.11. During
rolling upgrade, if client application is restarted on nodes, the client driver
may first contact an upgraded Cassandra node with v4 and
Hello Anuj,
The 2nd workaround should work. As app will auto discover all the other nodes.
Its the first contact with the node that app makes determines the protocol
version. So if you remove the newer version nodes from the app configuration
after the startup, it will auto discover the newer n
other concerns:
there is no replication between 2.11 and 3.11, store in hints, and replay
hints when remote is same version. have to do repair if over window. if
read quorum 2/3, will get error.
in case rollback to 2.11, can not read new version 3.11 data files, but
online rolling upgrade, some
There is replication between 2.1 and 3.x, but not hints. You will have to
repair past the window, but you should be doing that anyway if you care about
tombstones doing the right thing
Read quorum with 2/3 in either version should work fine - if it gives you an
error please open a JIRA with ste
> On Jul 5, 2018, at 12:45 PM, Anuj Wadehra
> wrote:
>
> Hi,
>
> I woud like to know how people are doing rolling upgrade of Casandra clustes
> when there is a change in native protocol version say from 2.1 to 3.11.
> During rolling upgrade, if client application is restarted on nodes, the