MySQL 8.0 Release Notes
MySQL 8.0 Source Code Documentation
This section explains how to set up a sandbox InnoDB cluster deployment. You create and administer your InnoDB clusters using MySQL Shell with the included AdminAPI. This section assumes familiarity with MySQL Shell, see MySQL Shell 8.0 (part of MySQL 8.0) for further information.
Initially deploying and using local sandbox instances of MySQL is a good way to start your exploration of InnoDB cluster. You can fully test out InnoDB cluster locally, prior to deployment on your production servers. MySQL Shell has built-in functionality for creating sandbox instances that are correctly configured to work with Group Replication in a locally deployed scenario.
Important
Sandbox instances are only suitable for deploying and running on your local machine for testing purposes. In a production environment the MySQL Server instances are deployed to various host machines on the network. See Section 21.2.4, “Production Deployment of InnoDB Cluster” for more information.
When you deploy a sandbox instance, a local directory is created and a copy of mysqld is stored. This copy matches the current version of MySQL server installed at the time of deploying the sandbox. Therefore the version of mysqld used for a sandbox is a fixed and does not change if you then upgrade the installed version of MySQL. As sandbox instances are considered transient and for testing, the quickest solution is to delete all sandboxes built on an old version before deploying new sandbox instances after an upgrade of MySQL.
This tutorial shows how to use MySQL Shell to create an InnoDB cluster consisting of three MySQL server instances.
MySQL Shell includes the AdminAPI that adds the
dba global variable, which provides
functions for administration of sandbox instances. In this
example setup, you create three sandbox instances using
dba.deploySandboxInstance().
Start MySQL Shell from a command prompt by issuing the command:
shell> mysqlsh
MySQL Shell provides two scripting language modes,
JavaScript and Python, in addition to a native SQL mode.
Throughout this guide MySQL Shell is used primarily in
JavaScript mode
. When MySQL Shell starts it is in JavaScript mode by
default. Switch modes by issuing \js for
JavaScript mode, \py for Python mode, and
\sql for SQL mode. Ensure you are in
JavaScript mode by issuing the \js command,
then execute:
mysql-js> dba.deploySandboxInstance(3310)
Note
Terminating commands with a semi-colon is not required in JavaScript and Python modes.
The argument passed to
deploySandboxInstance() is the TCP port
number where the MySQL Server instance listens for
connections. By default the sandbox is created in a directory
named
$HOME/mysql-sandboxes/
on Unix systems. For Microsoft Windows systems the directory
is
port%userprofile%\MySQL\mysql-sandboxes\.
port
The root user's password for the instance is prompted for.
Important
Each instance has its own password. Defining the same password for all sandboxes in this tutorial makes it easier, but remember to use different passwords for each instance in production deployments.
To deploy further sandbox server instances, repeat the steps followed for the sandbox instance at port 3310, choosing different port numbers. For each additional sandbox instance issue:
mysql-js> dba.deploySandboxInstance(port_number)To follow this tutorial, use port numbers 3310, 3320 and 3330 for the three sandbox server instances. Issue:
mysql-js> dba.deploySandboxInstance(3320)
mysql-js> dba.deploySandboxInstance(3330)The next step is to create the InnoDB cluster while connected to the seed MySQL Server instance. The seed instance contains the data that you want to replicate to the other instances. In this example the sandbox instances are blank, therefore we can choose any instance.
Connect MySQL Shell to the seed instance, in this case the one at port 3310:
mysql-js> \connect root@localhost:3310
The \connect MySQL Shell command is a
shortcut for the shell.connect() method:
mysql-js> shell.connect('user@localhost:3310')
Tip
Attempting to use instances with a host name that resolves to an IP address which does not match a real network interface fails. See Section 21.5, “Known Limitations”.
Once you have connected, AdminAPI can write to the local instance's option file. This is different to working with a production deployment, where you would need to persist settings to the instance's option file.
Use the dba.createCluster() method to
create the InnoDB cluster with the currently connected
instance as the seed:
mysql-js> var cluster = dba.createCluster('testCluster')
The createCluster() method deploys the
InnoDB cluster metadata to the selected instance, and adds
the instance you are currently connected to as the seed
instance. The createCluster() method
returns the created cluster, in the example above this is
assigned to the cluster variable. The
parameter passed to the createCluster()
method is a symbolic name given to this InnoDB cluster, in
this case testCluster.
Tip
If the instance has
super_read_only=ON then you
might need to confirm that AdminAPI can set
super_read_only=OFF. See
Super Read-only and Instances for more
information.
The next step is to add more instances to the InnoDB cluster. Any transactions that were executed by the seed instance are re-executed by each secondary instance as it is added. This tutorial uses the sandbox instances that were created earlier at ports 3320 and 3330.
The seed instance in this example was recently created, so it is nearly empty. Therefore, there is little data that needs to be replicated from the seed instance to the secondary instances. In a production environment, where you have an existing database on the seed instance, you could use a tool such as MySQL Enterprise Backup to ensure that the secondaries have matching data before replication starts. This avoids the possibility of lengthy delays while data replicates from the primary to the secondaries. See Section 18.4.7, “Using MySQL Enterprise Backup with Group Replication”.
Add the second instance to the InnoDB cluster:
mysql-js> cluster.addInstance('root@localhost:3320')The root user's password is prompted for.
Add the third instance:
mysql-js> cluster.addInstance('root@localhost:3330')The root user's password is prompted for.
At this point you have created a cluster with three instances: a primary, and two secondaries.
Tip
You can only specify localhost in
addInstance() if the instance is a
sandbox instance. This also applies to the implicit
addInstance() after issuing
createCluster().
Once the sandbox instances have been added to the cluster, the
configuration required for InnoDB cluster must be persisted
to each of the instance's option files. How you proceed
depends on whether the instance supports persisting
configuration changes automatically, see
Persisting Settings.
When the MySQL instance which you are using supports
persisting configuration changes automatically, adding the
instance automatically configures the instance. When the MySQL
instance which you are using does not support persisting
configuration changes automatically, you have to configure the
instance locally. See
Configuring Instances with
dba.configureLocalInstance().
To check the cluster has been created, use the cluster
instance's status() function. See
Checking a cluster's Status with
Cluster.status()
Once you have your cluster deployed you can configure MySQL Router to provide high availability, see Section 21.3, “Using MySQL Router with InnoDB Cluster”.