Picking a MySQL Clustering Deployment Method: Staging versus INI

Tungsten Clustering is an extraordinarily flexible tool, with options at every layer of operation.

In this blog post, we will describe and discuss the two different methods for installing, updating and upgrading Tungsten Clustering software.

When first designing a deployment, the question of installation methodology is answered by inspecting the environment and reviewing the customer's specific needs.

Staging Deployment Methodology

All for One and One for All

Staging deployments were the original method of installing Tungsten Clustering, and relied upon command-line tools to configure and install all cluster nodes at once from a central location called the `staging server`.

This staging server (which could be one of the cluster nodes) requires SSH access to all database nodes.

The simple steps include:

  1. cd to the top-level software staging directory. The default directory for extracting new tarballs is under /`opt/continuent/software`
  2. extract the software tarball
  3. cd into the newly-extracted directory
  4. configure with `tools/tpm configure`
  5. install using the `tools/tpm install` command

During execution, the `tools/tpm install` command uses SSH to install the Tungsten software on all nodes in the cluster in parallel. For example, you could install a 4-site composite cluster with 3 nodes per site across multiple global regions with a single command and all 12 nodes would be handled at once.

Future configuration updates would be handled the same way (i.e. via `tools/tpm update` from the extracted software directory), and normally would affect all the cluster nodes at once.

The `--no-connectors` option may also be used to allow for the graceful cycling of the Connector connectivity layer.

INI Deployment Methodology

The Strength of Individuality

The INI methodology was developed with two situations in mind - no SSH access, and the ability to support per-node configuration files for automation tools like Chef, Puppet and Ansible.

In this deployment model, an INI file is placed on every host associated with the cluster first (`/etc/tungsten/tungsten.ini` by default). This is the equivalent to running the `tools/tpm configure` step from the staging method.

In the INI world, any `tpm install` or `tpm update` reads the configuration for that one node and executes the install or update ON THAT NODE ONLY. The presence of an INI file tells `tpm` to limit install and update actions to the current host.

In Tungsten Clustering v4.0 and later, `tpm` will automatically search all INI files within the `/etc/tungsten` and current directories.

Once the INI file is populated on all cluster nodes, the procedure is similar to the staging method, except for the fact that it must occur on EVERY node individually.

The simple steps include:

  1. cd to the top-level software staging directory. The default directory for extracting new tarballs is under /`opt/continuent/software`
  2. extract the software tarball
  3. cd into the newly-extracted directory
  4. install using the `tools/tpm install` command

Note that the `tpm configure` step is gone since the configuration is now stored in the INI file.

Staging versus INI - Differences

What's the difference between the two methods of deployment?

Here are some of the key differences between Staging and INI deployments:


  • there is just one staging directory needed which resides on a single host (which may be a member cluster node or a separate host)
  • configuration is performed centrally in the staging directory on a single host
  • requires passwordless SSH
  • installs and updates multiple cluster nodes
  • provides a one-command cluster upgrade path


  • every node has a locally-extracted staging directory
  • configuration is performed locally on each node via the `/etc/tungsten/tungsten.ini` file
  • does NOT require passwordless SSH
  • installs and updates one single cluster node at a time
  • installs and updates must be performed on every node one-by-one
  • there is NO one-command cluster upgrade path
  • ideal for automated environments
  • possible to have multiple configuration files in /etc/tungsten

Click here to read more about "Comparing Staging and INI tpm Methods".

Staging versus INI - Decision

We always recommend the INI deployment for many reasons:

  • INI deployments have a very clear standard configuration location
  • INI deployments are very easy to tweak on a per-host basis
  • INI deployments are cloud and devops-friendly
  • INI is required for certain topologies (i.e. Composite Multimaster)

Deployment Type - How Do I Know?

Determining the deployment type after install

To determine which method your current deployment uses, check the output of:

shell> tpm query deployments | grep deployment_external_configuration_type
  "deployment_external_configuration_type": "ini",

If you see the value of "ini", then the INI method was used to deploy your cluster.


shell> ls -l /etc/tungsten/*
-rw-rw-r-- 1 tungsten tungsten 1347 Oct  5 16:06 /etc/tungsten/tungsten.ini

If you use the `ls` command and see at least one `.ini` file, then you are using the INI method to configure your cluster.

Staging Directory - How Do I Know?

Determining the staging directory location

To determine the staging directory location from where your cluster was installed, check the output of:

shell> tpm query staging
# Installed from tungsten@staging-host:/opt/continuent/software/tungsten-clustering-5.0.1-136

When using the INI method of configuration, the staging-host in the above example output would display the host name of the local host.

Tungsten Clustering is the most flexible, performant global database layer available today - use it underlying your SaaS offering as a strong base upon which to grow your worldwide business!

For more information, please visit https://www.continuent.com/solutions

Want to learn more or run a POC? Contact us.

About the Author

Eric M. Stone
COO and VP of Product Management

Eric is a veteran of fast-paced, large-scale enterprise environments with 35 years of Information Technology experience. With a focus on HA/DR, from building data centers and trading floors to world-wide deployments, Eric has architected, coded, deployed and administered systems for a wide variety of disparate customers, from Fortune 500 financial institutions to SMB’s.

Add new comment