Introduction

This is the user guide for the MySQL Cluster configuration tool. The aim of this tool is to help you install, configure and deploy NDB Cluster quickly using GUI. It is also a great learning tool. You can read the user guide sequentially, or you can get help regarding the wizard page you are currently at by choosing the proper entry in the Help menu. This user guide is divided into the following main parts:

Tool Name

The configuration tool is a part of the MySQL Cluster Software, and hence, it does not have a particular name. In this user guide, we refer to it as the (Auto)installer, configurator, configuration tool, configuration wizard, MCC or simply wizard.

Installing and Starting

The configuration tool is installed together with the MySQL Cluster software. Please refer to the regarding installation. This section describes the requirements to the environment of the tool, important information about security, and explains how to start the wizard.

Installation Layout

The configuration tool may end up in various locations depending on the context (note that the default paths may be overridden at install time for some package formats).

Limitations

Wizard Options

The wizard supports the following command line options:

If no options are given, we default to HTTP (-H) using self-signed certificate provided with the software. If you want to use HTTPS you have to add -S (or --use-https) to command line.

Starting the Wizard

First, you need to identify the directory where the ndb_setup tool is located. This location depends on which package was downloaded and how it was installed. Then, you can start in the following ways:

Supported Platforms

The configuration tool makes it a top priority to support the following platforms:

Additionally, the tool will attempt, as far as possible, to support the following platforms:

Supported Browsers

Development is based on ES6 specifications. Browsers not supporting it fully, like IE11, might not work properly.

The configuration tool makes it a top priority to support the following browsers:

Additionally, the following browsers are supported as far as possible:

There have been no issues detected with Microsoft Edge browser. However, IE insists on parsing DOJO requirements too early in the process which effectively disables loading DIJIT templates from cache thus forcing load from different domain. As cross-domain scripting is disabled in IE by default, should the problem occur, you will have to change Internet options/Security/Custom level under Miscellaneous/Access datasources across domains to ENABLE or PROMPT for MCC to work. Also, local sites can trigger "compatibility mode" in IE thus rendering happens with some decade old engine. In such case, uncheck Internet options/Advanced/Go to an intranet site for...

IE setting

IE11 doesn't support ES6 fully and receives no development from Microsoft so we may stop supporting it very soon.

Required Software

The following software must be installed on the host where the configuration tool is started:

If you install the Windows version of the configuration tool, the above software comes bundled and is installed automatically.

The following software must be installed on the remote hosts that will be used to deploy the MySQL Cluster:

Security

Three basic security mechanisms may be utilized by the configuration tool:

Wizard overview

Two main components comprise the cluster configuration tool:

The two main components communicate using messages wrapped in http(s). The back end can manage MySQL cluster software on any host. If the software is on the same host as the back end itself, the Python interfaces are used for file system operations, process manipulation, etc. If the MySQL Cluster software is on remote host, the back end relies on SSH access to that hosts, using the Paramiko package for executing commands remotely.

The remainder of this section will describe overall usage of the wizard in terms of navigating between pages, various settings, and how to get help.

Navigation

The configuration tool is implemented as a wizard with a number of pages covering different steps. There are two ways to navigate between pages. First, the navigation toolbar or breadcrumb trail displays the titles of the various pages. A specific page can be selected by clicking the page title:

Breadcrumb trail

In the breadcrumb trail, the title of the current page is highlighted. The advantage of the breadcrumb trail is that you can jump more than one page in either direction. The main feature is that navigation doesn't persist your configuration changes to external file making it preferred way when testing temporary changes and/or just jumping to Deploy Configuration page of already prepared configuration. You can also use this jump to attach to already running Cluster.

How can navigation via breadcrumb get you in trouble

Say you wanted to persist your changes, it won't happen. Maybe you made changes to number and/or arrangement or processes on Parameters page possibly invalidating configuration which was already deployed or started and skipping directly to Deploy page will not adjust parameter values thus resulting in failed deploy/start. And so on. Do not skip pages if you are not sure what you're doing.

Page buttons

The second navigation mechanism is to use the three navigation buttons at the bottom of the page. These can be used to advance to the next or previous page, or to go to the very last page. The buttons are disabled as needed, e.g., if you are at the last page, the Save&Next and Finish buttons are disabled, while if you are on the first page, the Previous button is disabled. If you are making changes to configuration you wish to persist over MCC sessions, you need to use Save&Next.

Getting Help

At the very top right in the wizard window you will find the Help menu:

Help menu

The various menu entries in the Help menu are:

In addition to the help menu, there are tool tips for most of the input widgets. They are displayed when you hover over the widget, or there is a small question mark next to the widget's label which can be hovered for help. For the configuration parameters, the parameter names are linked to the MySQL Cluster documentation, so if you click the parameter name, the appropriate documentation is displayed in a separate frame.

Internals

Back end is web server in Python. It is started with (s)bin/ndb_setup.py (or with setup.bat on Windows). Ultimately, ndb_setup.py reaches share/mcc/request_handler.py and MCC is started. request_handler is central script processing all the HTTP requests from front end (mcc/server/api.js).
First, it determines the type of request (resources info, management node status etc.), then it creates proper object by calling clusterhost::produce_ABClusterHost(). produce_ABClusterHost() determines whether the host towards which command is directed is local or remote and returns LocalClusterHost() or remote_clusterhost.RemoteClusterHost(). The only difference is that LocalClusterHost has no credentials attached to object. This newly created object is used to authenticate (RemoteClusterHost), run command and return result at which time it is destroyed. The entry point for request is def handle_req(req) and exit point is def make_rep(req, body=None). Synchronization is done via def make_rep where sequence number coming from front end is passed back in rSeq member:

rep: {'head': { 'seq': req['head']['seq'] +1,
    'cmd': req['head']['cmd'],
    'rSeq': req['head']['seq'] }
}
Some requests, like def handle_copyKeyReq(req, body) are self-sufficient and return but OK, some do the heavy lifting by employing appropriate routines in local/remote clusterhost objects like def handle_readCfgFileReq(req, body).
The most elaborate one is management command handler, def handle_runMgmdCommandReq(req, body). This routine creates permanent SSH connections to remote host(s) running ndb_mgmd process in setupMGMTConnection. Through this connection object, commands are sent to ndb_mgm client library to get status of all Cluster nodes which is then parsed and returned to front end properly formatted. runMgmdCommandReq can also process special input from front end, like "STOP" command which instructs it to clean up list of MGMTConnection objects. This happens, for example, when Cluster is stopped and you navigate away from Deploy Configuration page in front end and also when you terminate Python web server. If host running ndb_mgmd process is local, another mechanism is used, a socket connection socket.create_connection(localhost, port). There are several points to take into account here: Next to note is def start_proc(proc, body). This function is used to start, stop and, if necessary, kill Cluster processes on hosts. Each command object employing this function has procCtrl (process control) object attached. Most important members defined in "params" section are:
autoComplete: Should the 'bin', 'sbin', 'scripts'... directories get appended to path provided with command. This is important, for example, for defining path for Cluster binaries in front end (Hosts pageMySQL Cluster install directory). If you're running Cluster deployment on RPM/YUM platform, ndb_mgmd will be in /usr/sbin, while ndb_mgm will be in /usr/bin directory (same applies to mysqld and mysqladmin). So START/STOP command will utilize autoComplete and HOSTS::MySQL Cluster install directory should be set to just /usr/. There is no autoComplete for Windows host(s) meaning Hosts page, MySQL Cluster install directory should point all the way down to BIN (...\mysql-cluster-7.6-winx64\bin)
isCommand: This is a special flag used for, for example, service removal command on Windows which might need retrying.
exec_cmdv: We call this command to get actual work done. The behavior is governed with two more flags: waitForCompletion and daemonWait. If there is waitForCompletion but no daemonWait, we wait for command to return indefinitely. If there is waitForCompletion and daemonWait then we wait for daemonWait seconds before starting to poll for result of command every 0.5 seconds for another 2 minutes (localhost) or 3 minutes (for remote host). If it doesn't complete, (Remote)ExecException is risen. This is useful when issuing command we know will take some amount of time before completing (like starting data node processes) but we still want to be able to recover from failure (i.e. not wait indefinitely).
noRaise: Special flag telling exec_cmdv not to fail for specific return value (other than 0).
Next we check that procCtrl doesn't have kill member and treat such commands as "ordinary". Otherwise we proceed to special handling of commands with kill members where we first determine if recipient OS is Windows (procCtrl.servicename is not empty) or *nix since Windows require different handling due to fact that we install Cluster processes as services there. In general, when stopping Cluster, we first stop mysqld(s) by issuing mysqladmin --shutdown/net stop N5x with kill member and getPID member describing how to obtain PID for the concrete process (see deploy.js, getStopProcessCommands for details). If, for some reason, mysqladmin/net stop fails to stop mysqld(s) then we will obtain the PID(s) one by one and kill those mysqld processes. Things are bit trickier for Cluster processes. First we try to connect to primary management host and issue ndb_mgm -e"SHUTDOWN" there. If this fails, we try to kill the offending ndb_mgmd process. Then, if Cluster has second management node, we repeat the above on that host. Ultimately, if all management nodes (hosts running ndb_mgmd process) fail to take Cluster down, we will issue kill to all data node processes. This means killing both angel and data node process so "DNODE" is sent as special command and not "KILL". Data node processes also have additional member, procCtrl.getPIDchild, in addition to procCtrl.getPID (Angel/actual process).
Starting Cluster is bit simpler. First we start primary management process (ndb_mgmd) and then secondary (if present). After that we start all data node processes (ndbmtd) in parallel, and then all of mysqld processes also in parallel (except for IE11 where processes are started sequentially).

The approach of one ClusterHost object per command helps with resources and synchronization but it's slow. So we introduced permanent SSH connections to all of remote hosts in ConnArr list of paramiko.SSHClient() objects which are extended with several new members explaining host OS, CPU etc. Thus first command going to remote host is going to be much slower than subsequent ones. If you are creating new Cluster, this will probably be getting resource info. If you are working with already defined Cluster, probably Start Cluster command. This list of SSH connections is maintained and checked for stale connections upon each new command. It is released once you stop Python process in console to exit MCC.

Finally, on Windows, we have noticed Python web server going to "sleep" on occasion. This manifests as if nothing is happening in front end. So if you notice, for example, progress bar not advancing at all for longer period of time, click on Python console and press ENTER key once or twice to get things going again. You should see logging resuming. Also, Windows Server OS tends to ignore Ctrl+C in Python shell. If so, use Ctrl+Break to exit properly.
Cleaning up lists of SSHClient() objects upon exit:
^C received, shutting down web server
17:01:13,091: WARNING [cleanupMGMTConnections;request_handler.py:98]: Cleaning up MGMT connections array.
17:01:13,091: WARNING [cleanupConnections;remote_clusterhost.py:61]:  Cleaning up connections array.
Removing C:\Users\user_name\mcc.pid
Terminate batch job (Y/N)? y

Cluster is started if management process is running and and responds to client poll for status. For example, mysqld process may start (green light on DEPLOY page) and then die (red light on DEPLOY page) but we still consider Cluster started. To investigate what happened with specific command to start failing SQL node, you can check JavaScript console, click View commands or click Cluster tools and choose Get log files.
Cluster is stopped if all mysqld processes can not be polled for status and ndb_mgm client reports management process begun Cluster shutdown procedure. If this fails, we kill the processes. Assuming standard shutdown procedure is in effect (ndb_mgm -e'SHUTDOWN') the processes tree on DEPLOY page will show some processes as running even after we alert you Cluster has stopped. Just wait 5-10 seconds for all statuses to refresh.

Wizard Pages

This section will describe the various wizard pages in detail.

Welcome

Welcome page

The first page displayed after the ndb_setup command is invoked is the Welcome page. Here, you have three major areas:

When you click RUN configuration, the back end server will get contacted to read from chosen configuration and pass it back. This information will then get attached to window.name environment variable and passed to next page where it will be loaded into in-memory stores.
Providing existing configuration name when prompted for "New configuration" name is not treated as error. Instead, MCC will simply read the existing configuration and proceed.

Configuration files

Configurations are files with .mcc extension residing in current user's HOME/.mcc directory. The name of the file is copied to "Cluster name" member of ClusterStore. File consists of saved contents of 5 in-memory stores:
  1. ClusterStore: Single entry, encompassed in {}
  2. HostStore: Array of as many entries as there are hosts in Cluster, encompassed in {}
  3. EmptyStore: Just {}, placeholder for processTypeStore
  4. processStore: Array of as many entries as there are processes in Cluster, encompassed in {}
  5. processTreeStore: Array of as many entries as there are families of processes in Cluster, encompassed in {}
1) ClusterStore:
{
	"identifier": "id",
	"label": "name",
	"items": [
		{
			"id": 0,
			"ssh_keybased": "on",
			"ssh_user": "",
			"savepwds": false,
			"name": "v39-v40-frigg",
			"apparea": "simple testing",
			"writeload": "low",
			"installCluster": "NONE",
			"openfw": false,
			"Started": true,
			"ssh_ClKeyUser": "my_username",
			"ssh_ClKeyFile": "",
			"ssh_ClKeyPass": "-"
		}
	]
}
This array has just one member ("id": 0,) meaning there can be only one Cluster configuration per file. The rest represents various choices available on Define Cluster page.

2) HostStore:
{
	"identifier": "id",
	"label": "name",
	"items": [
		{
			"id": 5,
			"name": "Any host",
			"anyHost": true
		},
		{
			"id": 6,
			"name": "External IP or FQDN of 1st host",
			"anyHost": false,
			"openfwhost": false,
			"installonhost": false,
			"SWInstalled": true,
			"hwResFetch": "OK",
			"hwResFetchSeq": 2,
			"ram": 524155,
			"cores": 88,
			"uname": "Windows",
			"osver": "10",
			"osflavor": "Microsoft Windows 10 Enterprise",
			"dockerinfo": "NOT INSTALLED",
			"datadir_predef": true,
			"diskfree": "418G",
			"fqdn": "myhost1.mydomain.org",
			"internalIP": "10.172.165.189",
			"installonhostrepourl": "",
			"installonhostdockerurl": "mysql/mysql-cluster:7.6",
			"installonhostdockernet": "",
			"installdir": "E:\\MCCtest\\server\\bin\\",
			"installdir_predef": false,
			"datadir": "C:\\Users\\user\\MySQL_Cluster\\"
		},
		{
			"id": 7,
			"name": "External IP or FQDN of 2nd host",
			"anyHost": false,
			"openfwhost": false,
			"installonhost": false,
            ...
	]
}
This array has as many members as there are hosts in Cluster. Key to linking this store with processStore is "id" field which is always different for every host (HostStore.id=processStore.host). It does not need a link to ClusterStore since there can be just one Cluster configuration per file.
The lowest ID is always reserved for dummy entry "Any host" which serves to initialize empty store. It is the only entry with "anyHost": true!
The rest represent various choices available on Define Hosts page.

4) processStore:
{
	"identifier": "id",
	"label": "name",
	"items": [
		{
			"id": 9,
			"name": "Management node 1",
			"host": 6,
			"processtype": 0,
			"NodeId": 49,
			"seqno": 1
		},
		{
			"id": 10,
			"name": "Management node 2",
			"host": 7,
			"processtype": 0,
			"NodeId": 50,
			"seqno": 2
		}, 
        ...
		{
			"id": 15,
			"name": "SQL node 2",
			"host": 8,
			"processtype": 3,
			"NodeId": 54,
			"seqno": 2,
			"Port": 3308
		},
        ...
		{
			"id": 17,
			"name": "Multi threaded data node 2",
			"host": 8,
			"processtype": 2,
			"NodeId": 2,
			"seqno": 2
		}
	]
}
This array has as many members as there are processes running on Cluster hosts. Key to linking this store with host store is "host" field (ID in HostStore).
If you change some parameter on process level, it will be recorded here. For example, you can see that mysqld process id=15, running on host=8 has Port=3308 which is not the default setting thus recorded here.
The rest represent various choices available on Define Processes and Define Parameters pages.

5) processTreeStore:
{
	"identifier": "id",
	"label": "name",
	"items": [
		{
			"id": 0,
			"name": "ndb_mgmd",
			"family": "management",
			"familyLabel": "Management layer",
			"nodeLabel": "Management node",
			"minNodeId": 49,
			"maxNodeId": 50,
			"currSeq": 2
		},
		{
			"id": 1,
			"name": "ndbd",
			"family": "data",
			"familyLabel": "Data layer",
			"nodeLabel": "Single threaded data node",
			"minNodeId": 1,
			"maxNodeId": 9,
			"currSeq": 3,
			"NoOfReplicas": 2,
			"FragmentLogFileSize": 64,
			"NoOfFragmentLogFiles": 16
		},
        ...
	]
}
This array has as many members as there are process families running on Cluster. Families are hardcoded into MCC thus this field will always be of same size. So, if you change some parameter on family level (i.e. value is the same for all processes of the same family), it will be recorded here. For example, you can see that data family has NoOfReplicas=2, FragmentLogFileSize=64 and NoOfFragmentLogFiles=16 which applies to all processes belonging to data family (processStore.processtype 1 and 2). The link is processTreeStore.ID=ProcessStore.processtype ( 0 - management family, 1 and 2 - data family (ndbd/ndbmtd), 3 - sql family and 4 - API family).
The rest represent various choices available on Define Parameters page.
We do not encourage editing configuration files, however, sometimes it might be the fastest way to transfer settings from one Cluster to the other.

Define Cluster

On Define cluster page you can decide on overall settings for the cluster you are going to configure. Setting provided here are "Cluster-wide" meaning for every host added, if there are no per-host entries, these will be used. This allows for quick deployment of configurations where there is just localhost or where, for example, credentials are the same for every host in Cluster (cloud deployment). There are also receipts for various Cluster settings depending on what you want (see below). Please note that you can override any of the settings here later in the process.
Edits on this page are disable while Cluster configured is running.

Define cluster

The page contains following fields:

Cluster properties: various Cluster level properties SSH Property: Here you can specify the use of SSH credentials to access remote host(s). If your host list (see above) only contains 127.0.0.1, no SSH credentials are required. Install properties: Here you define Cluster installation parameters as well as firewall manipulation. Changes monitor: Four buttons at lower-left showing if there were modifications to configuration.

Define cluster

To view what changed, just click the button:

Define cluster

Password reminder:

If passwords were present at Cluster level in previous run, look for red labels and put your passwords into their respective input field(s).

Define cluster

OCI deployment tips: When creating deployment on Oracle cloud infrastructure, you should check "Key based SSH" and enter "opc" into "Key user". Provide "Key passphrase" if your key is encrypted. If your key file is different than ~/.mcc/id_rsa.pub, you should put it, with fully qualified path, to "Key file". Also make sure "Install MySQL Cluster" is set to "REPO"(/"BOTH") and check "Open ports in firewall". To take full advantage of MCC capabilities, please use instances with RPM/YUM OS such as Oracle Linux. For RPM/YUM platforms and default install, "MySQL Cluster install directory" should be set to "/usr/".

How can this page get you into trouble

If you enter any credentials here you won't be able to change them for particular host on Hosts page, i.e. credentials entered here are used for all hosts.
If you're installing on RPMYUM platform, be sure to pick right Cluster Version and REPO installation.

The Save&Next button sends asynchronous request for your changes to be saved to configuration file and advances to next page. If you close the wizard here, or use breadcrumb navigation, no changes you made will be saved unless special event, like successful start of Cluster, occurs. However, even if not saved, changes will persist throughout current browser session.

Define Hosts

After the overall cluster properties have been defined, you can refine the host details as well as define new hosts here.
Edits on this page are disable while Cluster configured is running.
The wizard page is shown below:

Define hosts

Password reminder:

If passwords were present for some hosts during previous run, you will be notified to reenter them on this page. In concrete example, you need to select host "192.168.56.102" and click Edit selected host. On that screen you need to reenter ordinary password (no SSH authentication selected for this host). After saving changes, select host "192.168.56.101", click Edit selected host and on new screen enter passphrase for public key used (SSH authentication is checked for this host)

Define hosts

Here, hosts can be added by clicking the Add hosts button and entering host name (host external ip address) as well as credentials. Field Key_file should point to private key file to be used with selected host (i.e. C:\Users\user\.ssh\key_file_name). If the key has default name (id_rsa), it will be automatically picked up by Paramiko.
Host name (Host external ip address): IP address making host accessible from the box MCC is running on.
Host internal ip address: Host IP address inside VPN or external IP address if no VPN is used. Imagine you have five hosts Cluster running in Oracle Cloud then, in this field, you would enter the IP address used inside cloud service for safer and faster communication between hosts. If your instances are RPM/YUM OS, such as Oracle Linux, this information will be provided for you. We also try and guess InternalIP on other platforms but do not fill it in unless absolutely certain. Our best guess on InternalIP will be logged in JavaScript console for you to check: 

[INF]Array of IP's is:
(index)     Values
    0       192.168.56.1
    1       192.168.0.105

Define hosts

If you fetched hosts resources, the platform name, RAM size and number of CPU cores will be filled in automatically and displayed in the grid. Otherwise, an ellipsis in the grid will indicate that the information was not obtained. The status of the resource information fetching is displayed in the Resource info column. Please note that fetching the information may take some time. Should the resource fetch fail, correct the host information by clicking Edit selected host and refetch by clicking Refresh selected host(s).

If the SSH user credentials on Define Cluster page are changed, the tool will try to re-fetch the hardware information for hosts where a piece of information is missing. When the information is re-fetched, the various fields will be updated. If a field has been edited by the user, the information will not be overwritten by the re-fetched value.

The hardware resource information, platform name, install directory, data directory and free disk space can be edited by the user by clicking the appropriate cell in the grid. It is also possible to select a host and press the button Edit selected host. Then, a dialog will appear where various fields can be edited. The edited values will be applied to selected host:

Edit selected hosts

Please note that REPO/DOCKER install details are available for editing only on this screen.
Turning your attention to two more things: I do not have "User" supplied. This is indicative of my key being id_rsa and placed in ~/.ssh. If I supply "Passphrase", this would mean my id_rsa is encrypted.
Also, I am deploying Cluster in VPN so I have proper IP address, not accessible from the outside, in "Host internal IP" box. This will allow Cluster to skip resolving names.

Details on hosts naming

One should always keep in mind the goal, i.e. deployment of the Cluster processes over any number of hosts. Thus we refer to Hosts via their external IP address and not FQDN, for example, even though it is possible. I.e., for anything other than simple deployment just on localhost, you should follow these rules:


The nodes are governed by config.ini file, distributed to each management node, containing hosts designation on per process basis as well as connection strings. It might look like this:
[NDB_MGMD]
NodeId=49
HostName=10.172.165.190
DataDir=C:/Users/user/MySQL_Cluster/49/
Portnumber=1186

[NDBD]
NodeId=2
HostName=10.172.162.24
DataDir=C:/Users/user/MySQL_Cluster/2/
In this particular case, HostName=10.172.162.24 is actually localhost. The reason to define it as 10.172.162.24 and not "localhost" lies in that when config.ini is distributed to second host, 127.0.0.1 will point to that host (10.172.165.190) and the Cluster will not start. This is why you cannot mix 127.0.0.1/localhost with remote hosts.
We strongly advise using Internal IP field when adding/editing hosts if Cluster is running inside VPN (say Cloud deployment).

Let's recapitulate various scenarios: MCC will always use Host (Host external IP) member to connect, distribute configuration and start processes. Configuration files and Cluster processes will always use what is configured. If it's InternalIP, communication between nodes will be as fast as possible and bypassing any errors on DNS level.

The hosts currently entered are displayed in the grid with various pieces of information. A host, or a selection of hosts, can be removed from the configuration by pressing Remove selected host(s). If processes have been configured to run on these hosts, the processes will be removed from the configuration too.

Finally, HostGrid can have two states, collapsed (default):

HostGrid collapsed

and expanded:

HostGrid collapsed

toggled by Show/Hide extended info button. Images show actual settings for OCI deployment.

If you are using per-host credentials and not Cluster level ones, after editing hosts, you should SHIFT-Click to select them all and press Refresh selected host(s) to check connections work and fill in various data for hosts.

How can this page get you into trouble

Forgetting to refresh hosts info can lead to unpredictable results. For example, maybe disk space is running low or you entered bad credentials and so on.
If you changed DataDir(s) or Platform be sure to visit Define Parameters page and make sure all is fine with groups of processes and processes.
If you removed host be sure to visit both Define Processes and Define Parameters page and make sure all is fine with groups of processes and processes. Same goes for adding the host to configuration.

The Save&Next button sends asynchronous request for your changes to be saved to configuration file and advances to next page. If you close the wizard here, or use breadcrumb navigation, no changes you made will be saved unless special event, like successful start of Cluster, occurs. However, even if not saved, changes will persist throughout current browser session.

Define Processes

After the hosts have been defined, the next step is to define which processes should be part of the cluster and the way they will be distributed.
Edits on this page are disable while Cluster configured is running.
The page is shown below:

Define processes

There are two main areas here, there is a process tree to the left, with the various hosts and the processes configured to run on them. To the right is an information pane which displays information about the currently selected item in the tree. When the user enters this page the first time for a cluster configuration, a set of processes is defined by default. The processes defined depend on the number of hosts. If the user goes back to the previous page, removes all hosts, and adds new ones, then a new set of processes will be defined.

The processes are of the following main types:

In the process tree to the left, each node has a numeric suffix, which is incremented for each new process of that type. This is just to be able to tell the different processes apart. In the tree, in addition to the hosts you enter, there is a special entry Any host. This special "host" is really just a placeholder where processes that should be allowed to run on an arbitrary host may be located. Usually, a process is configured to run on a specific host, and thus will not be allowed to run on an arbitrary host. If this is desirable, the process should be added to the Any host entry. Please note that only API processes may be located under special entry Any host.

In the process tree, you can right click a host for a pop up menu displaying an entry Add process. Selecting this entry will take you to the Add new process dialog. Alternatively, you can select a host, and press the Add process button below the process tree. The add process dialog lets you select among the available process types, and you can also enter an arbitrary process name instead of the default suggestion:

Add process

In the tree, you can also right click a process and select delete process from the pop up menu, or select a process and press the Del process button below the process tree. If a process is selected in the process tree, information about that process is displayed in the information pane to the right. You may edit the process name, and you may change the process type to another compatible type. Currently, the only compatible process types are the two variants of the data node; single threaded or multi threaded. If you want to change to an entirely different type, you need to delete the process first, and then add a new process with the desired type.

How can this page get you into trouble

Say you have old configuration which you already started one or more times with even number of DATA processes. Then you decide to add/remove some processes. Say you remove 1 SQL process and add 1 DATA process. If you skip Define Parameters page and go directly to Deployment page not all variables will be properly set. For example, NoOfReplicas for even number of DATA processes (started configuration) is 2 but for odd (new configuration) is 1. Visiting Define Parameters page and checking on processes and families will warn you about this:
Trouble processes
We also removed one SQL process and skipping directly to Deploy page can result in hanging start of SQL processes.

In short, if you made any changes here, make sure everything is fine on Define Parameters page and consider redeploying Cluster, even, maybe, deleting old data from DataDirs.

The Save&Next button sends asynchronous request for your changes to be saved to configuration file and advances to next page. If you close the wizard here, or use breadcrumb navigation, no changes you made will be saved unless special event, like successful start of Cluster, occurs. However, even if not saved, changes will persist throughout current browser session.

Define Parameters

The page for defining parameters looks somewhat similar to the previous page (Define Processes).
Edits on this page are disable while Cluster configured is running.
To the left is a tree with the processes, to the right is a pane with information regarding the currently selected tree item:

Define parameters

However, looking at this in more detail, we see that the process tree is organized differently. On the previous page, it reflected which hosts the processes were running on, whereas on this page, it shows the processes grouped by process type. Thus, the root nodes in the tree are the process types (families), and the children are the process instances. You may notice that the compatible processes are grouped into the same process type, hence, the two data node processes will both be in the Data layer process type.

Below the process tree, you will see a check box labeled Show advanced configuration parameters. This check box will make advanced parameters visible or hidden in the information pane to the right. If you, select the Data layer process group, you will see that toggling the check box makes a lot of parameters appear or disappear in the pane to the right. The significance of this visibility is only that the parameters need to be visible for you to be able to change them. The parameters will be set anyway (if nothing then to default values) and used in the configuration of the cluster.

The purpose of this page is to define the various configuration parameters for the processes. This can be done in two main ways:

When a process group or process instance is selected, you will see the following information in the pane to the right (for SQL process):

Parameters for mysqld

In the information pane shown above, you see the various parameter names, their values, and for some of them, there is also a green button with a plus sign to the right. That button means that the parameter can be overridden. Thus, if you push the button, the input widget for the parameter will be enabled, and you will be able to change its value. The various parameters will have predefined values. If you look at the parameter DataDir, for example, you will see it is a predefined path. This path is constructed based on the host on which the process will run, taking the data directory you entered for this host on the Define Hosts page, and appending the node id. All configuration parameters displayed by the tool will have predefined values, and usually, the values may just be left as they are. It is highly recommended that you read the documentation before making changes to the parameter values. Each parameter name is a hyper link to the MySQL documentation, so it is easy to find the relevant information.

If a configuration parameter has been changed, you may revert the change and go back to the predefined value: When the value has been overridden, the green button with a plus sign turns into a big red X, as shown below:

Overriding parameters

If you press this red X, the change is reverted and the parameter is reset to predefined value.

There are circumstances where changing parameter value or reverting to default is not possible. Imagine you started Cluster with one Data node and then stopped it. NoOfReplicas in such case would be 1. Then you add more hosts/data nodes to your Cluster but it is not possible to change NoOfReplicas to higher value as this would lead to original data node process not starting. In such case, it is best to delete all DATADIRs (loosing all data) and redeploy or leave NoOfReplicas as it was (1).

How can this page get you into trouble

Any number of things can be changed on this page leading to troubles starting the configuration. Most notably, NoOfReplicas is set according to number of DATA processes (1 for odd, 2 for even) and it's not possible to restart Cluster using old data once this value changes.
There is a documentation link alongside every option and it would be prudent to use it before changing things.
This page also makes sure to assign proper port numbers to processes on same/different hosts and this change can require new deployment.

The greatest trouble for you comes from not checking on this page.

The Save&Next button sends asynchronous request for your changes to be saved to configuration file and advances to next page. If you close the wizard here, or use breadcrumb navigation, no changes you made will be saved unless special event, like successful start of Cluster, occurs. However, even if not saved, changes will persist throughout current browser session.

Deploy Configuration

The last page in the wizard is the deployment page. Here, you can inspect the startup commands and actual configuration files that will be applied, you can distribute the configuration files and create the necessary files and directories on the hosts involved, and you can start and stop the cluster you have configured. Currently, Install cluster button is in effect only for hosts running Oracle Linux or compatible RPM/YUM OS. The page looks similar to the previous one:

Deploy configuration

To the left, you will find the same process tree as on the previous page. The processes are listed grouped by the process type they belong to. To the right of the process tree, there are two information panes. The upper one will display the startup commands necessary to start the process. For some processes, more than one command may be required. The lower pane will show the contents of the configuration file for the given process. Currently, the only processes having a configuration file are the management and sql nodes. The data node processes are configured by means of command line parameters submitted with the startup command or by getting their configuration parameters by asking the management nodes dynamically.

In the process tree, the icons in front of the processes will change depending on the status of the processes. I.e., when the cluster starts or stops, the icons will turn red (stopped), yellow (starting or stopping) or green (running). This status information is based on querying the management daemon by means of ndb_mgm client library.

Below the process tree, you will find six buttons:

If you left the configuration running and closed the MCC session, upon next load of the same configuration MCC will realize Cluster is up providing you entered missing credentials.

Below is an example of a progress bar displayed while starting the cluster:

Starting cluster

When it's impossible to tell the progress of the process (for example, when it's run in back end) or when process status is determined by means other than command returning (starting data/sql nodes) then we show indeterminate progress bar:

Deploying cluster

It is worth noticing that the configuration tool cannot guarantee that the cluster is available for usage when it has been started. Some processes may need some time to initialize before they are ready for usage.

How can this page get you into trouble

Make sure to observe Changes monitor when arriving to this page:
Change monitor
If any of the buttons is red, review your changes by clicking both the red and G(eneral) button to make sure if new deployment or even removal of old data is needed to start the configuration.
Here, people usually forget to deploy, which, in some cases can lead to unstartable configuration. Rule of thumb is, if any of the parameters changed, by you or automatically, new deployment is needed.
Make sure to redeploy and remove old data when appropriate.
Useful command to run is Verify configuration. It runs automatically before Deploy and Start but you can also find it in Cluster tools menu. Here is a sample of mocked errors:
Verify trouble
First we have IP address that is invalid in general but since I opted to use VPN, InternalIP member of Host store is checked.
Then we have address not belonging to private range entered into InternalIP member of Host store.
Then we have ExternalIP address entered into Internal which obviously does not satisfy private range check.
This all makes configuration invalid.
Then we check if all hosts use IP addresses consistently.
Finally, since I added 3rd DATA process, NoOfReplicas changed from 2 to 1 making this configuration unstartable without redeployment and deletion of old DataDirs.


Quick start on Oracle Cloud Infrastructure


Troubleshooting & FAQ

 Viewing the Logs
Logs can be found in HOST:MySQL Cluster data directory/NODEID. DATADIR can be configured for each host individually and the defaults for different OS can be found in storage/MCCStorage.js file: 
SunOS: {
    installdir: "/usr/local/bin/",
    datadir: "/var/lib/mysql-cluster/"
},
Linux: ...{
Important ones are: For my 6 node test Cluster running on OL7.6 this translates to 
~/MySQL_Cluster/1/ndb_1_out.log,
~/MySQL_Cluster/2/ndb_2_out.log,
~/MySQL_Cluster/49/ndb_49_cluster.log and ~/MySQL_Cluster/49/ndb_49_out.log,
~/MySQL_Cluster/53/data/mysqld.53.err and ~/MySQL_Cluster/54/data/mysqld.54.err
On Windows, "~" expands to "C:\Users\user\" and on Linux to "/home/user/". We strongly recommend using "~/MySQL_Cluster/" for DATADIR. Worth mentioning here is that, upon failure to start Cluster, MCC will alert you to these exact locations.
You can also use Cluster tools, Get log files command to fetch and examine logs locally.

MCC fails to fetch all logs:
There is a known problem with Paramiko sftp-ing big files (hundreds of MB) as described in paramiko/issues/926 on GiTHub. Someone suggested you change the value of MAX_REQUEST_SIZE in Paramiko sftp_file.py to 1024.
Bear in mind, all other (lazy) methods of download will take "forever".

MCC fails to locate Cluster binaries during START:
The location of binaries is governed by HOST:installdir setting. Since MCC has to locate both Cluster and client binaries this might not provide enough info (except on Windows) since Cluster binaries are usually in "sbin" and client ones in "bin". This is why MCC will take HOST:installdir setting and try following combinations HOST:installdir/sbin, HOST:installdir/bin and "" when locating binaries. Effectively, for OL7.X, this means HOST:installdir should be set to "/usr/". Empty string "" means MCC will use no designation (binaries are added to PATH).
When installing Cluster from MCC, or when you have installed SW to default places, you should put parent directory into HOST:installdir. As we said, for Oracle Linux it would be "/usr/", for Windows, "C:\Program Files\MySQL\MySQL Server Version\bin" (do not forget the "bin"!) and so on.

What does "WARNING" I see in Python console mean:
Text such as 
[TS]: WARNING  [handle_fileExistsReq;request_handler.py:495]: FER result is 1.
is for debugging purposes and not the actual warning from the code. Since the default DEBUG level is too verbose, it might be better to switch to WARNING level (start Python process with -d WARNING) when running MCC.

Starting and Stopping MySQL Cluster
Starting MySQL Cluster happens in sequence: Stopping MySQL Cluster happens in reverse: You may observe the actual commands sent both in JS console and in Python output. Commands can be preserved for further inspection by clicking View commands.
There might be a slight delay between end of STOP procedure and all processes changing icon in the tree.

My configuration changes are not saved
This can happen when you use "breadcrumb" toolbar instead of Save&Next button to navigate MCC. Usage scenario for Save&Next button is when you either define new cluster or make changes to existing one. Usage scenario for navigating the tool via "breadcrumb" is to quickly START already configured Cluster, STOP already running Cluster (jump from 1st to last page of MCC) or just browse through settings. In short, using "breadcrumb" does not trigger saving of configuration.
Also, there is automatic saving of changes. For example, when Cluster successfully starts, configuration will be saved.

I initiated START procedure but it appears stuck
Depending on Cluster settings, startup procedure can take up significant amount of time. Please refer to Cluster documentation or books for further details. In general, using predefined configurations (apparea: "simple testing", writeload: "low"), starting single process should not take more than a minute. It is worth checking Python console too and pressing ENTER key once or twice there to get things going. If you still feel startup is stuck, you can close the progress window and examine the logs. You will also have to check for started processes over the host(s) and kill them manually or with Stop cluster.

All is fine with my Cluster and configuration, still START/STOP/DEPLOY/INSTALL procedure appears stuck
On Windows boxes, we have noticed Python web server going to "sleep" on occasion. This manifests as if nothing is happening in front end. It is enough to click on Python console and press ENTER key one or two times to get things going again.
Installation should take about 5-10 minutes regardless of number of hosts depending on how fast their internet connection is. Deploy/Start/Stop should take about 1-2 minutes regardless of number of hosts in Cluster.
Unless you use IE11.
When adding Data nodes to your Cluster you have to account for time needed to sync them. Depending on lots of factors, this can take couple of minutes. This is log from data nodes I took to illustrate the situation:
Old data node process starts in matter of seconds: 
    
2019-05-20 11:51:20 [ndbd] INFO     -- Angel pid: 5552 started child: 5553
2019-05-20 11:51:20 [ndbd] INFO     -- Normal start of data node using checkpoint and log info if existing
...
2019-05-20 11:51:30 [ndbd] INFO     -- Grant nodes to start phase: 102, nodes: 0000000000000006
2019-05-20 11:51:30 [ndbd] INFO     -- Node started
New data node process needs much more time to report as started: 
    
2019-05-20 11:51:22 [ndbd] INFO     -- Angel pid: 16638 started child: 16639
2019-05-20 11:51:22 [ndbd] INFO     -- Normal start of data node using checkpoint and log info if existing
...
2019-05-20 11:52:15 [ndbd] INFO     -- Phase 101 was used by SUMA to take over responsibility for sending...
2019-05-20 11:52:15 [ndbd] INFO     -- Node started


What are some good practices you can recommend?
Do not use more than 2 MGMT nodes.
Put SQL and DATA nodes on same host.
When replacing old host with new one, it is best to delete old host and enter new one fresh.
Do not use IE11.

Cluster fails to start on my Windows box:
Starting Cluster on Windows requires Administrator privileges. This means that you need to start MCC (setup.bat) from elevated shell (Administrator: Command prompt). Also, you need to be Administrator on all Windows boxes that are part of Cluster.

There is too much output in Python console:
Change logging level to "WARNING":

Windows: Edit setup.bat, change "-d DEBUG" to "-d WARNING".
Linux: Pass -d WARNING to ndb_setup.

Unable to start Python web server:
    Running out of install dir: ...mysql-cluster-7.6-winx64\bin
Traceback (most recent call last):
    File "...mysql-cluster-7.6-winx64\bin\ndb_setup.py", line 38, in module
        request_handler.main(mcc_config.install_prefix, mcc_config.abs_install_subdir)
    File "...mysql-cluster-7.6-winx64\share\mcc\request_handler.py", line 1333, in main
        if is_port_available(options.server_name, port_val):
    File "...mysql-cluster-7.6-winx64\share\mcc\util.py", line 87, in is_port_available
        return try_connect(url_host, port, False, _retdict('ECONNREFUSED', True))
    File "...mysql-cluster-7.6-winx64\share\mcc\util.py", line 63, in try_connect
        s = socket.create_connection((url_host, port))
    File "C:\Python27\lib\socket.py", line 575, in create_connection
        raise err
socket.error: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions
This is indicative of firewall and/or security policy blocking the access to HTTP server. Fix and retry.

I have configuration that has already been started but now I rearranged processes over Cluster hosts. What should I do:
Go to Deploy Configuration page.
If you have added new host, you will have to click Install cluster button. If Cluster was previously started, you will be prompted to install just new host(s).
Click Cluster tools button. Choose "Delete all data and files" command. Your DATA is gone!
Click Deploy cluster.
ALERT this will DELETE all the data you might have saved in Cluster!
Click Start cluster.
Alternatively you might try skipping "Delete all data and files" command and see if new configuration is startable. You can always delete DATADIRs later.

I am planning to run some scripts from within Cluster but it's inside VPN. What should I do:
Go to Deploy Configuration page.
Click Cluster tools button. Choose "Copy SSH keys" command.
Upon completion, you will be prompted about external IP address of host able to access all other hosts in Cluster. Copy your scripts there and run your scripts from that host.

Where can I see exact commands MCC issued:
Go to Deploy Configuration page.
Click View commands button. The commands will be displayed in pop up window as well as saved to ~/.mcc/YYYY-MM-DD_HH-MM_cmdslog.txt file for further reference.
Check Python console.
Check web console.

I added more Data nodes and now my Cluster won't start:
From Deploy Configuration page, remember the NodeID of Data node failing to start. Probably the first one you added.
Click Cluster tools, Get log files button. Examine ~/.mcc/YYYY-MM-DD_HH-MM_ndb_NodeId_out.log for errors. Usual one is "Illegal configuration change"
NumberOfReplicas changed: -- Illegal configuration change. Initial start needs to be performed when changing no of replicas (1 != 2)
Go to Define Parameters page and revert offending values back. Go to Deploy Configuration page and redeploy and start the Cluster. If reverting to default value is not possible, see next line.
Usually, best way to deal with this is to clean up DATA directories and start fresh.

How do I remove information dialog from screen?
Click anywhere on MCC page, press ESC key or click little X in upper right corner.
Some information dialogs have time-to-live and will disappear on their own after few seconds. Usually such dialogs leave note in JavaScript console too.

I had reminder about badly configured hosts but it's not showing any more:
To reduce number of dialogs popping up, we show most of them only once. To see what the message was about, you can click G general log button.

What are these information buttons and why do they turn red or green?


The data about your configuration and changes is stored in in-memory stores. The information buttons represent their "shadow" which is synced only upon successful deployment or start of configuration. Until such time comes, "shadows" are monitoring your changes and noting those that are relevant for deployment and start of Cluster. Should any such important change happen, it will get noted and the button will go red. If not, it will stay green.
First button monitors ClusterStore, second HostStore and third Processes and Parameters Store.
Last button never goes red as it's general changes button which logs important and regular changes to configuration as well as some notifications we've shown.

I had failed Start and Stop left rouge processes running on hosts:
Even if Cluster appears stopped, you can re-run Stop commands in an effort to remedy the situation.
    
    [ERR]Error occurred while starting cluster DATA node :
    Command `/usr/sbin/ndbmtd --ndb-nodeid=3 --ndb-connectstring=10.0.0.246:1186,10.0.0.245:1186,',
        running on 129.146.116.59 exited with 1
    [ndbd] INFO -- Angel connected to '10.0.0.246:1186'
    [ndbd] ERROR -- Failed to allocate nodeid, error:
        'Error: Could not alloc node id at 10.0.0.246 port 1186: No node defined with id=3 in config file.'

This is an example where I cooked up above failure by doing numerous insane things which, in turn, made whole lot of mess. Old DATA nodes 1 and 2 failed to start, management process 49 (primary) stopped itself but not the secondary, SQL processes failed to start completely and include into Cluster and so on and so on. This is when you try to stop the "stopped" cluster.
Also, look into Python console/Commands log, it will give you and idea of which commands you need to execute to get things to shut down manually. Normal way:
    
[19:18:01]STOPTCL::SUCC::mysqladmin --port=3306 --user=root shutdown --socket=/home/opc/MySQL_Clusterv2/54/mysql.socket
[19:18:14]STOPTCL::SUCC::ndb_mgm localhost 1186 --execute=shutdown --connect-retries=2

Kill processes:
    
[16:27:45]STOPTCL::SUCC::kill -9 $(cat /home/opc/MySQL_Cluster/1/*.pid)
[16:27:55]STOPTCL::SUCC::kill -9 $(cat /home/opc/MySQL_Cluster/2/*.pid)

We recommend to always try and stop Cluster properly.

What does failure in commands log mean?
There are failures
    
[17:01:39]CHKFILE::FAIL::129.146.79.107:/home/opc/MySQL_Clusterv2/54/data/:auto.cnf
[17:01:40]CHKFILE::FAIL::129.146.116.59:/home/opc/MySQL_Clusterv2/49/:ndb_49_config.bin.1
which are normal (here they mean configuration files are not found so we need to Deploy) and failures that are rather serious, you should use your better judgement when viewing them.
Usually, when things go wrong, I look into commands log, Python/JavaScript console and download log files from remote hosts to examine what went wrong.

Paramiko takes too long to connect/fail?
There is a known problem in Paramiko when you provide wrong credentials described here and here.