Deploys a new MySQL/MariaDB Replication or a standalone MySQL/MariaDB server. The database cluster will be automatically added into ClusterControl once deployed. A minimum of two nodes is required for MySQL/MariaDB replication. If only one database IP address or hostname is provided, ClusterControl will deploy it as a standalone MySQL/MariaDB server with binary log enabled.
By default, ClusterControl deploys MySQL/MariaDB replication with the following configurations:
MySQL GTID with log_slave_updates enabled (MySQL and Percona only).
MariaDB GTID with log_slave_updates enabled (MariaDB only).
All database nodes will be configured with read_only=ON and super_read_only=ON (if supported). The chosen master will be promoted by disabling the read-only in the runtime.
Performance Schema is disabled.
ClusterControl will create and grant necessary privileges for two MySQL/MariaDB users – cmon for monitoring and management and backupuser for backup and restore purposes.
The generated account credentials are stored inside secrets-backup.cnf under the MySQL configuration directory.
ClusterControl will configure semi-synchronous replication.
If you would like to customize the above configurations, modify the template base file to suit your needs before proceeding to the deployment. See Base Template Files for details.
Starting from version 1.4.0, it’s possible to set up a master-master replication from scratch under the Define Topology tab. You can add more slaves later after the deployment completes.
ClusterControl sets read_only=ON on all slaves but a privileged user (SUPER) can still write to a slave (except for MySQL versions that support super_read_only).
General & SSH Settings
Specify root if you have root credentials.
If you use sudo to execute privileged system commands, specify the name that you wish to use here. The user must exist on all nodes. See Operating System User.
SSH Key Path
Specify the full path of the SSH key (the key must exist on the ClusterControl node) that will be used by SSH User to perform passwordless SSH. See Passwordless SSH.
If you use sudo with a password, specify it here.
Ignore this if SSH User is root or sudoer does not need a sudo password.
Note that it is important for the MOTD to be escaped properly. See Sudo Configuration.
Specify the SSH port for the target nodes. ClusterControl assumes SSH is running on the same port on all nodes.
Specify a name for the cluster.
Check the box if you use clean and minimal VMs. Existing MySQL dependencies will be removed. New packages will be installed and existing packages will be uninstalled when provisioning the node with the required software.
If unchecked, existing packages will not be uninstalled, and nothing will be installed. This requires that the instances have already provisioned and installed the necessary software.
Check the box to disable the firewall (recommended).
If unchecked, ClusterControl will skip this step and will not touch the existing firewall rules.
Check the box to let ClusterControl disable AppArmor (Ubuntu) or SELinux (RedHat/CentOS) if enabled (recommended).
If unchecked, ClusterControl will skip this step and will not touch any AppArmor/SELinux related configurations.
Location of MySQL data directory. Default is /var/lib/mysql.
MySQL server port. The default is 3306.
MySQL configuration template file under /etc/cmon/templates or /usr/share/cmon/templates. See MySQL → Manage → Configurations → Base Template Files for details.
Specify the MySQL root password. ClusterControl will configure the same MySQL root password for all instances in the cluster.
Use Vendor Repositories – Provision software by setting up and using the database vendor’s preferred software repository. ClusterControl will always install the latest version of what is provided.
Do Not Setup Vendor Repositories – Provision software by using repositories already set up on the nodes. The user has to set up the software repository manually on every database node as well as all future database/load balancer nodes in this cluster. Commonly, this is the best option if the database nodes are running without internet connections.
Use Mirrored Repositories – Create and mirror the current database vendor’s repository and then deploy using the local mirrored repository. This is a preferred option when you have to scale the cluster in the future, to ensure the newly provisioned node will always have the same version as the rest of the members. Depending on the database vendor and version, this might eat up the disk space of the ClusterControl host significantly.
Master A – IP/Hostname
Specify the IP address/hostname/FQDN of the primary MySQL master node and press Enter. ClusterControl will perform a sanity check if the specified host is reachable via passwordless SSH. You should see a green tick icon appears next to the hostname if everything is good.
Add slaves to master A
Add a slave node connected to Master A. Press Enter to add more slaves.
Add Second Master Node
Opens the add node wizard for the secondary MySQL master node.
Master B – IP/Hostname
Only available if you click Add Second Master Node.
Specify the IP address/hostname/FQDN of the other MySQL master node. ClusterControl will setup a master-master (circular) replication between these nodes. Master B will be read-only once deployed (secondary master), letting Master A holds the writing role (primary master) for the replication chain.
Add slaves to master B
Only available if you click Add Second Master Node.
Add a slave node connected to Master B. Press Enter to add more slaves.