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?

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?

You can keep it like this in 7.1 and FDB will do a default split of (I believe) 1:4 of grv:commit proxies. You probably want to do some benchmarks to ensure this ratio makes sense for the workload pattern of your cluster(s).

1 Like

Thank you!

Also, is there any plan to support arm64 in production? From what I understand, currently support is only for mac m1 based local dev.

where can download 7.x pachages, i only see 6.3 in this link
https://apple.github.io/foundationdb/downloads.html#client-server-packages