Updating 6.0 -> 6.2

doublemax · August 8, 2019, 9:23am

Could I update 6.0 to 6.2 (skipping 6.1)?

markus.pilman · August 8, 2019, 4:21pm

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).

ajbeamon · August 8, 2019, 4:27pm

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:

github.com

apple/foundationdb/blob/release-6.2/documentation/sphinx/source/administration.rst

##############
Administration
##############

.. include:: guide-common.rst.inc

.. toctree::
   :maxdepth: 1
   :hidden:
   :titlesonly:

   configuration
   moving-a-cluster
   tls

This document covers the administration of an existing FoundationDB cluster. We recommend you read this document before setting up a cluster for performance testing or production use.

.. note:: In FoundationDB, a "cluster" refers to one or more FoundationDB processes spread across one or more physical machines that together host a FoundationDB database.

To administer an externally accessible cluster, you need to understand basic system tasks. You should begin with how to :ref:`start and stop the database <administration-running-foundationdb>`. Next, you should review management of a cluster, including :ref:`adding <adding-machines-to-a-cluster>` and :ref:`removing <removing-machines-from-a-cluster>` machines, and monitoring :ref:`cluster status <administration-monitoring-cluster-status>` and the basic :ref:`server processes <administration_fdbmonitor>`. You should be familiar with :ref:`managing trace files <administration-managing-trace-files>` and :ref:`other administrative concerns <administration-other-administrative-concerns>`. Finally, you should know how to :ref:`uninstall <administration-removing>` or :ref:`upgrade <upgrading-foundationdb>` the database.

This file has been truncated. show original

doublemax · August 8, 2019, 5:41pm

Thanks a lot!
Best wishes

alexmiller · August 15, 2019, 2:10am

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.)

ThomasJ · August 16, 2019, 11:08pm

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, …)?

alexmiller · August 16, 2019, 11:33pm

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.

ThomasJ · August 17, 2019, 12:01am

javascript :\

Thank you for the pointers

ThomasJ · August 27, 2019, 8:00pm

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?

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.

ajbeamon · August 27, 2019, 8:13pm

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.

ThomasJ · August 27, 2019, 11:41pm

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.

ajbeamon · August 28, 2019, 1:57am

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.

ThomasJ · August 28, 2019, 5:38pm

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.

ajbeamon · August 28, 2019, 7:01pm

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.

ThomasJ · August 28, 2019, 11:43pm

Super helpful. Thank you