In FoundationDB, a cluster refers to one or more FoundationDB processes spread across one or more physical machines that host a FoundationDB database. A single FoundationDB server process can perform multiple roles.
A FoundationDB server process uses one CPU core per process. If you have multiple physical CPU cores on the machine, then you should run one FoundationDB server processes for each CPU core (using [fdbserver.<id>] option in foundationdb.conf)
FoundationDB releases are of the form major.minor.patch (X.Y.Z).
Major/minor releases of FoundationDB are always protocol incompatible, and patch releases are always protocol compatible.
When upgrading the cluster it is important to watch if the transaction logs have large queues (which can happen when the cluster is in saturation or cluster is recovering from machine failure) [fn:1].
The way to perform an upgrade is to manipulate symbolic links [fn:2]. If need be, foundationdb.conf should also be updated. Once we are all set, fdbcli --exec kill will force all processes in the cluster to reboot the at sametime. Once the reboot is complete, fdbmonitor will run the new version.
When doing an upgrade, in case the there is an fdbserver restart by accident, then it would prematurely switch to the new version. For patch version upgrade the new version is allowed to communicate with the old version, so the database will continue operating as usual. For major/minor version upgrade, the new version will attempt to talk to the old version, and its communications will be rejected. This is equivalent to that process being down until the upgrade is finished.
fdbmonitor need not be upgraded at every release. You can upgrade fdbmonitor only if you need features from it [fn:3].
When it comes to upgrading the client, in fdb_c_options.g.h, there is an option FDB_NET_OPTION_EXTERNAL_CLIENT_DIRECTORY, which specifies the location of directory where libfdb_c_X.Y.Z.so shared library can be found. Language bindings [fn:4] provides a way to set this directory.
In fdb_c_options.g.h, there is also the option FDB_NET_OPTION_CLIENT_THREADS_PER_VERSION. This option is used to start multiple worker threads, where each worker thread would communicate with one cluster. This feature is useful when client is actively using more than one cluster.
[fn:1] Forums - Upgrading FoundationDB
[fn:2] Fourms - Upgrading FoundationDB
[fn:3] Forums - Upgrading FoundationDB
[fn:4] Forums - How to setup multi-version clients with Java?