I want to upgrade the Pulsar brokers in a pulsar cluster (from 2.6.3 to 2.10.1)
The question is could I just upgrade the brokers to 2.10.1 (and leave other components (Bookkeeper as well ZooKeeper) in 2.6.3)
(Asking this because according to this https://pulsar.apache.org/docs/administration-upgrade, I am not sure if I also need to upgrade BookKeeper or not)
Thank you !
2.6.3 contains a very old version of ZooKeeper (3.5.x) and from Pulsar 2.8.x onwards we require ZooKeeper 3.6.x because Pulsar uses the Persistent Recursive Watches feature.
I suggest to upgrade ZooKeeper and BookKeeper as well, at least to Pulsar 2.8.x.
As a general rule of thumb in Pulsar is that we support rolling upgrades from one major version to the next (so from 2.6 to 2.7...).
Jumping from 2.6 to 2.10 is not supported officially, but it should work.
Related
Apache Pulsar supports geo-replication between clusters in different regions. I am wondering if there are any compatibility issues between clusters running different version of Pulsar.
The question is for planning purposes, so that I know whether I need to upgrade one of the clusters or not.
Geo-replication is compatible between all clusters running the same major version of Pulsar, e.g., 2.x
I'm planning to upgrade my 100+ nodes cassandra baremetal cluster with current version 2.2.19.
Please let me know if I can upgrade from 2.2.19 to 3.11 directly ?
Also what is the timeline to wait to upgrade to next version i.e from 3.11 -> 4.x, can I upgrade to the latest version ( 2.2.19 -> 3.11 -> 4.x ) in single upgrade plan ?
Thank you
It isn't an issue upgrading a Cassandra 2.2.19 cluster directly to the latest 3.11 release.
There is no requirement to have a break to upgrade to C* 4.x -- upgrading the nodes isn't going to be an issue at all. What you need to be concerned with is whether you need to upgrade the driver you're using.
If you do need to upgrade the driver, you need to refactor your application if the new version of the driver is not binary-compatible with the old version. For example, upgrading from Java driver 3.x to 4.x has breaking changes (see the Java driver v4 Upgrade Guide for details).
Before upgrading your cluster, make sure you familiarise yourself with the upgrade instructions for the various releases:
Cassandra 3.11 NEWS.txt
Cassandra 4.0 NEWS.txt
Cassandra 4.1 NEWS.txt
I need to migrate from Cassandra 1.2.9 to 3.11.
The plan is to go like this: 1.2.9-> 2.0.11 -> 2.2.* -> 3.11
Do you consider that is better to upgrade the cluster or to migrate data from 1.2.9 to 2.2 and after that to 3.11?
Is anything that you can consider a blocker?
I started from those threads:
Upgrading Cassandra 1.2.9 to 2.0.x
upgrade apache cassandra from 2.0.11 to 3.11
Migration will require additional hardware also you may not have continuous traffic going for you with migration. Do the upgrades as mentioned in upgrade guides/ instructions. You will do well going upgrade way.
Is it possible to upgrade Apache Cassandra 2.1.9+ to Apache Cassandra 3.1+ directly?
The release notes for 3.0 mention direct upgrades need a minimum of Apache Cassandra 2.1.9+, but all further releases of Apache Cassandra don't mention whether an intermediate version is needed.
Yes, you can upgrade from Cassandra 2.1.9 (or higher) to Cassandra 3.1 (or higher).
As stated in the DataStax dev blog in June of 2015, Cassandra moved to a "tick-tock" release cycle with version 3. The details of which you can get from the link, but the main point is that the release structure of 3.x is not the same as it was with 2.x.
Cassandra 2.0, 2.1, and 2.2 were different enough in terms of features and storage modifications that they required a structured upgrade path. Cassandra 3.x does not. You can upgrade directly to 3.1, 3.4, or 3.10 (just released). As long as you meet the 3.0 upgrade requirements (Cassandra version >= 2.1.9) you don't need to worry about intermediate upgrades with the 3.x line.
As per my experience about upgrading Cassandra if you are doing upgrade from below 2.1.9 then you must upgrade to 2.1.9 or above then you can directly upgrade to 3.x version. There is no issue in this way and you upgrade will be successful but if you are doing it on production make sure to do rolling upgrade with all prerequisites and backup. Don't forget to run nodetool upgradesstables after Cassandra upgrade.
When upgrading from 2.2.8 to 3.11.6 , while upgrading the last node in the cluster, when last node on which the upgrade is left the client is not able to connect to cluster untill upgrade on the last node finishes. We are having a 5 node cassandra cluster running on aws ec2.
Do we have to upgrade to interim version DSE 4.6 then go for 4.8 ?
we are using DSE 4.5.1 for our Cassandra db only .
You should be able to upgrade to 4.8.x from 4.5.y.
Cassandra major release (e.g. 2.1 to 3.0) or major point release (e.g. 2.0 to 2.1), might involve sstable version change which will require running upgradeSSTables from nodetool. Cassandra sstable versions are normally backward compatible with previous version but not before that. That’s why if you want to say upgrade to 2.2 from 2.0 then you would first upgrade to 2.1. While you are doing a rolling upgrade to 2.1 from 2.0 your cluster will be in mixed mode (some nodes still on 2.0 while other upgraded to 2.1). This will be OK because Cassandra will support reading from previous sstable version. But before you can upgrade to 2.2 you need to upgrade sstables. Once that is done (nodetool upgradesstables) on all the nodes then you can upgrade to 2.2.
In above example I have talked about Apache Cassandra version, but similar logic can be applied to DSE. Here is a link of which Cassandra version is used by various DSE and other upgrade related info
upgradedDSE47or48
The usual restrictions and limitation apply while cluster is in mixed mode as mentioned here