| Option |
Description |
mysql_server_addresses=<string> |
- A comma-separated list of MySQL hostnames or IP addresses (with or without port is supported). For MySQL Cluster, this should be the list of MySQL API node IP addresses. In the case of Galera Cluster, you can add
?slave or ?bvs (backup verification server) to the URL so ClusterControl will register the node accordingly.
- Example:
mysql_server_addresses=192.168.0.11:3306,192.168.0.12:3306,192.168.0.13:3306,192.168.0.14:3306?slave
|
monitored_mysql_port=<integer> |
- MySQL port for the managed cluster. ClusterControl assumes all DB nodes are listening on the same port. Default is 3306.
- Example:
monitored_mysql_port=3306
- Other aliases:
cmon_local_mysql_port,local_mysql_port
|
monitored_mysql_root_user=<string> |
- MySQL root user for the managed cluster. ClusterControl assumes all DB nodes are using the same root user. The user must have the same privileges as root (SUPER with GRANT OPTION). This is required when you want to scale your cluster by adding a new DB node or replication slave. Default is “root”.
- Example:
monitored_mysql_root_user=dbadmin
|
monitored_mysql_root_password=<string> |
- MySQL root password for the managed cluster. ClusterControl assumes all DB nodes are using the same root password. This is required when you want to scale your cluster by adding a new DB node or replication slave.
- Example:
monitored_mysql_root_password='r00tP$@^%sw0rd‘
|
skip_name_resolve=<boolean integer> |
- Setting to disable name resolution. Default is 1 means
skip_name_resolve is enabled.
|
mysql_version=<string> |
- The MySQL/MariaDB major version.
- Example: mysql_version=5.7.
- Other alias:
server_version
|
galera_port=<integer> |
- Exclusive for Galera Cluster. The Galera communication port to be used when adding nodes/garbd, and constructing
wsrep_cluster_address. Default is 4567.
|
galera_version=<string> |
- Exclusive for Galera Cluster. The Galera API major version number.
- Example:
galera_version=3.x
|
galera_vendor=<string> |
- Exclusive for Galera Cluster. The database vendor name. Supported values are “percona”, “codership” and “mariadb”.
- Example:
galera_vendor=mariadb
|
repl_user=<string> |
- The MySQL replication user.
- Example:
repl_user=repluser
|
repl_password=<string> |
- Password for
repl_user
- Example:
repl_password='ZG04Z2Jnk0MUWAZK‘
|
replication_failover_whitelist=<string> |
- A comma-separated list of MySQL slaves that should be used as potential master candidates. If no server on the whitelist is available (up/connected) the failover will fail. If this variable is set, only those hosts will be considered. This parameter takes precedence over
replication_failover_blacklist
- Example:
replication_failover_whitelist=192.168.1.11,192.168.1.12
|
replication_failover_blacklist=<string> |
- A comma-separated list of MySQL slaves will never be considered a master candidate. You can use it to list slaves that are used for backups or analytical queries. If the hardware varies between slaves, you may want to put here the slaves which use slower hardware.
replication_failover_whitelist takes precedence over this parameter if it is set.
- Example:
replication_failover_blacklist=192.168.1.101,192.168.1.102
|
replication_skip_apply_missing_txs=<boolean integer> |
- Default is 0. Skip the check process for additional missing transactions before promoting a slave to a master and just use the most advanced slave. Such a process may result in a serious problem though – if an errant transaction is found, replication may be broken.
- Example:
replication_skip_apply_missing_txs=1
|
replication_stop_on_error=<boolean integer> |
- Default is 1. ClusterControl will perform the MySQL master switch only once and will be aborted immediately if the switchover fails unless the controller is restarted or you specify this variable to 0.
- Example:
replication_stop_on_error=0
|
replication_failover_wait_to_apply_timeout=<integer> |
- The candidate waits up to this many seconds to apply outstanding relay log events (
retrieved_gtids) before failing over. Default is -1, which means ClusterControl will wait indefinitely for it to apply all missing transactions from its relay logs.
- This is safe, but, if for some reason, the most up-to-date slave is lagging badly, failover may take hours to complete. If set to 0, failover happens immediately, no matter if the master candidate is lagging or not. Default -1 seconds (wait forever). A value higher than 0 means ClusterControl will wait for the specified seconds before failover happens.
- Example:
replication_failover_wait_to_apply_timeout=0
|
replication_stop_on_error=<boolean integer> |
- Failover/switchover procedures will fail if errors are encountered that may cause data loss. Enabled by default. 0 means disable, default is 1 (true).
- Example:
replication_stop_on_error=0
|
replication_auto_rebuild_slave=<boolean integer> |
- If the SQL THREAD is stopped and the error code is non-zero then the slave will be automatically rebuilt. 1 means enable, default is 0 (false).
- Example:
replication_auto_rebuild_slave=1
|
replication_onfail_failover_script=<path> |
- Path to the failover script on ClusterControl node. This script executes as soon as it has been discovered that failover is needed. If the script returns non-zero it will force the failover to abort. If the script is defined but not found, the failover will be aborted.
- 4 arguments are supplied to the script:
- arg1=”All servers in the replication”
- arg2=”The failed master”
- arg3=”Selected candidate”
- arg4=”Slaves of old master”
- The arguments will be passed like this:
failover_script.sh "arg1" "arg2" "arg3" "arg4". The script must be accessible on the controller and executable.
- Example:
replication_onfail_failover_script=/usr/local/bin/failover_script.sh
|
replication_pre_failover_script=<path> |
- Path to the failover script on ClusterControl node. This script executes before the failover happens, but after a candidate has been elected and it is possible to continue the failover process. If the script returns non-zero it will force the failover to abort. If the script is defined but not found, the failover will be aborted.
- 4 arguments are supplied to the script:
- arg1=”All servers in the replication”
- arg2=”The failed master”
- arg3=”Selected candidate”
- arg4=”Slaves of old master”
- The arguments will be passed like this:
pre_failover_script.sh "arg1" "arg2" "arg3" "arg4". The script must be accessible on the controller and executable.
- Example:
replication_pre_failover_script=/usr/local/bin/pre_failover_script.sh
|
replication_post_failover_script=<path> |
- Path to the failover script on ClusterControl node. This script executes after the failover has happened. If the script returns non-zero, a warning will be written in the job log. The script must be accessible and executable on the controller.
- 4 arguments are supplied to the script:
- arg1=”All servers in the replication”
- arg2=”The failed master”
- arg3=”Selected candidate”
- arg4=”Slaves of old master”
- The arguments will be passed like this:
post_failover_script.sh "arg1" "arg2" "arg3" "arg4". The script must be accessible on the controller and executable.
- Example:
replication_post_failover_script=/usr/local/bin/post_failover_script.sh
|
replication_post_unsuccessful_failover_script=<path> |
- Path to the script on the ClusterControl node. This script is executed after the failover attempt failed. If the script returns non-zero a Warning will be written in the job log. The script must be accessible on the controller and executable.
- 4 arguments are supplied to the script:
- arg1=”All servers in the replication”
- arg2=”The failed master”
- arg3=”Selected candidate”
- arg4=”Slaves of old master”
- The arguments will be passed like this:
post_fail_failover_script.sh "arg1" "arg2" "arg3" "arg4". The script must be accessible on the controller and executable.
- Example:
replication_post_unsuccessful_failover_script=post_fail_failover_script.sh
|
replication_failed_reslave_failover_script=<path> |
- Path to the script on the ClusterControl node. This script is executed after that a new master has been promoted and if the enslaving of the slaves to the new master fails. If the script returns non-zero a Warning will be written in the job log. The script must be accessible on the controller and executable.
- Example:
replication_failed_reslave_failover_script=/usr/local/bin/fail_reslave_failover_script.sh
|
replication_pre_switchover_script=<path> |
- Path to the switchover script on ClusterControl node. This script executes before the switchover happens. If the script returns non-zero it will force the switchover to fail. If the script is defined but not found, the switchover will be aborted. The script must be accessible on the controller and executable.
- 4 arguments are supplied to the script:
- arg1=”All servers in the replication”
- arg2=”The failed master”
- arg3=”Selected candidate”
- arg4=”Slaves of old master”
- The arguments will be passed like this:
pre_switchover_script.sh "arg1" "arg2" "arg3" "arg4". The script must be accessible on the controller and executable.
- Example:
replication_pre_switchover_script=/usr/local/bin/pre_switchover_script.sh
|
replication_post_switchover_script=<path> |
- Path to the switchover script on ClusterControl node. This script executes after the switchover happened. If the script returns non-zero a Warning will be written in the job log. The script must be accessible on the controller and executable.
- 4 arguments are supplied to the script:
- arg1=”All servers in the replication”
- arg2=”The failed master”
- arg3=”Selected candidate”
- arg4=”Slaves of old master”
- The arguments will be passed like this:
post_switchover_script.sh "arg1" "arg2" "arg3" "arg4". The script must be accessible on the controller and executable.
- Example:
replication_post_switchover_script=/usr/local/bin/post_switchover_script.sh
|
replication_check_external_bf_failover=<boolean integer> |
- Before attempting a failover, perform extended checks by checking the slave status to detect if the master is truly down, and also check if ProxySQL (if installed) can still see the master. If the master is detected to be functioning, then no failover will be performed. Default is 0 (false) meaning the checks are disabled. 1 means enable.
- Example:
replication_check_external_bf_failover=0
|
replication_check_binlog_filtration_bf_failover=<boolean integer> |
- Before attempting a failover, verify filtration (
binlog_do/ignore_db) and replication_* are identically configured on the candidate and the slaves. Default is 0 (false) meaning the checks are disabled. 1 means enable.
- Example:
replication_check_binlog_filtration_bf_failover=1
|
replication_failover_events=<boolean integer> |
- Automatically failover events (SLAVESIDE_DISABLED) and enable the event_scheduler after a replication failover/switchover action. Default is disabled. Enabled by setting it to 1.
- Example:
replication_failover_events=1
|
auto_manage_readonly=<boolean integer> |
- Enable/Disable automatic management of the MySQL server
read_only variable. Default is 1 (true), which means ClusterControl will set the read_only=ON if the MySQL replication role is a slave. Default is 1 (enabled).
- Example:
auto_manage_readonly=0
|
schema_change_detection_address=<string> |
- This option must be defined to use “Operational Report for Schema Change”. Creating a report of thousands of database objects (schemas, tables, etc) will take some time (about 5-10 minutes) depending on the hardware. It’s recommended to configure a specific host to run this job for example on a replication slave or an asynchronous slave connected to e.g a Galera or Group Replication Cluster. For NDB this option should be set to a MySQL server used for admin purposes.
- Example:
schema_change_detection_address=192.168.111.53
|
schema_change_detection_pause_time_ms=<integer> |
- Throttle the detection process by pausing every this value, in milliseconds. For example, if defined as 3000, ClusterControl will pause the operation for every 3 seconds.
- Example:
schema_change_detection_pause_time_ms=3000
|
schema_change_detection_databases=<string> |
- A comma-separated string of database names and also supports wildcards. For example ‘
DB%’, will evaluate all databases starting with “DB”.
- Example:
schema_change_detection_databases=mydb%,shops_db,mymonitoring
|
datanode_addresses=<string> |
- Exclusive for MySQL Cluster. Comma-separated list of data node hostnames or IP addresses.
- Example:
datanode_addresses=192.168.0.41,192.168.0.42
|
mgmnode_addresses=<string> |
- Exclusive for MySQL Cluster. Comma-separated list of management node hostnames or IP addresses.
- Example:
mgmnode_addresses=192.168.0.51,192.168.0.5.2
|
ndb_connectstring=<string> |
- Exclusive for MySQL Cluster. NDB connection string for the cluster.
- Example:
ndb_connectstring=192.168.0.51:1186,192.168.0.52:1186
|
ndb_binary=<string> |
- Exclusive for MySQL Cluster. NDB binary for data node. Supported values are
ndbd or ndbmtd.
- Example:
ndb_binary=ndbmtd
|
ndbd_datadir=<path> |
- Exclusive for MySQL Cluster. The datadir of the NDBD nodes.
- Example:
ndbd_datadir=/var/lib/mysqlcluster
|
mgmd_datadir=<path> |
- Exclusive for MySQL Cluster. The datadir of the NDB MGMD nodes.
- Example:
mgmd_datadir=/var/lib/mysql
|
db_configdir=<string> |
- Exclusive for MySQL Cluster. The datadir of the NDB MGMD nodes.
- Example:
db_configdir=/etc/mysql-cluster
|