FoundationDB Upgrade 6.2.x -> 7.x

We are planning to upgrade from 6.2.x → 7.x
Are there any docs/ discussions I can refer to understand what is the best approach for upgrading.
Are there any known limitations?

2 Likes

Any help here is much appreciated.

For upgrading I would suggest doing 6.2 → 6.3 → 7.1 and not directly 6.2 → 7.1 (I’m actually not sure if this is supported and well-tested). The following doc explains how an upgrade can be performed: Upgrading FoundationDB · apple/foundationdb Wiki · GitHub, make sure that your clients have both library version ready before doing the actual restart/upgrade of the FDB cluster. There are also some older forum post around upgrades in general: Upgrading FoundationDB. If your cluster is running on Kubernetes you might want to look at the operator docs to understand how the operator performs the upgrade: fdb-kubernetes-operator/technical_design.md at main · FoundationDB/fdb-kubernetes-operator · GitHub.

One of the limitations for version upgrades is (at least for major/minor upgrades) that those versions are protocol incompatible and you have to upgrade all fdbserver processes “at once” otherwise they are not able to communicate.

2 Likes

So, does upgrade from 6.3->7.2 works without going to 7.1?
What is blocking the direct jump from 6.2->7.1? Does FDB do some kind of reindexing to the existing data ? Or is it just not being tested?

I’ve verified 6.2->7.1 can succeed. fyi.

Thank you everyone for the inputs.

Currently our cluster is 6.2.15. We are planning to take 6.2.15 → 6.3.25 and then 7.1.25 upgrade path.

We also pre-determine the number of coordinators, storage, transaction and proxy classes and specify in foundationdb.conf file in each node. Looks like proxy role has been split to grv_proxies and commit_proxies roles in 7.x. Does just specifying class = proxy still work in 7.x or do we need to split that equally between grv_proxies and commit_proxies?