Updating 6.0 -> 6.2

Using FoundationDB
1

Could I update 6.0 to 6.2 (skipping 6.1)?

2

You should be able to upgrade directly to 6.2 (we have tests for upgrades from 5.1.7 to 6.2). However, keep in mind that downgrading back to 6.0 wonā€™t be possible anymore as the default storage hash sums changed. This means that you can only go backwards from 6.2 to 6.1 (and even then you canā€™t go back from 6.1 to 6.0 if youā€™ve ever ran with 6.2).

3

Also, we usually try to list any version-specific upgrade notes in our documentation:

https://apple.github.io/foundationdb/administration.html#version-specific-notes-on-upgrading

Our docs on the website are still for the 6.1 version, but you can see the 6.2 version here:

4

Thanks a lot!
Best wishes

5

Note that we are still missing tests for doing this, so the downgrade capability isnā€™t actually promised, I think? (Iā€™m honestly a bit confused on this myself.)

6

A random question. Is there a way to find out which version we are running from the fdbcli?

To add to this, is there way to see which process is recruited as what (storage, log, ā€¦)?

7

fdbcli is actually version specific currently, so if your fdbcli connects to the cluster, then fdbcli --version is the cheap way to do it.

Otherwise fdbcli> status json and then looking at json.cluster.processes.ProcessID.version will give you the version that process is running.

status json also provides this, but GitHub - poma/fdbtop: Display and update sorted information about FoundationDB processes displays it in a nicer way.

2 Likes
8

javascript :\

Thank you for the pointers

9

I wrote my own parser based on this template.

I can see the assignment and where it came from but not the recruitment. How do I know which process is used for what?
04

What Iā€™m trying to find out is what FDB is deciding between the manual assignment and recruitment to identify issues.

Also, separate question. I was looking if I can obtain the same data directly from a driver instead of going through the fdbcli as it makes things a bit more complicated. I would much rather just pull everything in a single binary and not have to deal with the fdb installation.

10

You can see what a process is doing by looking at the ā€˜rolesā€™ section of a processā€™s status (cluster.processes.<process_id>.roles). It contains a list of objects each representing a role that the process is currently running, and you can get the name of the role (e.g. ā€˜storageā€™, ā€˜proxyā€™) from the role field of each object in the list.

To get the status json document from a client, you can read the key \xff\xff/status/json.

11

This is what I was looking for. If the role is empty, does it mean that no role was assigned and that process is not utilized?

Wow. Is still document automatically generated by the server? Or can you give me some pointers on it? Just curious.

12

Thatā€™s basically right, although until an upcoming 6.2 release the coordinator is not listed in the roles. That means that depending on the version, a process with an empty list could still be fulfilling the duties of coordinator.

This returns the same JSON document that you would get by calling status json in fdbcli. Itā€™s just meant to be another API thatā€™s usable by any client. I donā€™t think we have this or any other similar keys documented anywhere, though we definitely should.

13

This is good to know.

Can you give me a sense how this is being produced? When I call read on that key, what happens next? Do all the servers pool the data in real time and return them or do they generate this as they go and store it in that key continuously?

Would love to know what other keys are there.

14

This key is a sort of magic key, i.e. one that isnā€™t actually read from the database. When you ā€œreadā€ it, it triggers the same mechanism on the client that captures status in fdbcli. At a high level, this involves talking to the cluster controller, who then does a variety of status collection and includes some data obtained by communicating with other processes in the cluster. It returns the result, the client adds a few things to it, and then the document gets returned to you.

It looks like the main other two are documented here:

https://apple.github.io/foundationdb/administration.html#accessing-cluster-file-information-from-a-client

There are also a couple that can be used for the purposes of killing processes in the cluster, but they are a little bit more complicated and Iā€™ll defer the description of those to a documentation task.

15

Super helpful. Thank you