MySQL Variables and Parameters

This article summarizes the variables that are most frequently changed and most likely to affect results in the public mysql_ansible entry playbooks, so you can quickly locate the right configuration entry before deployment, backup, restore, and monitoring integration.

1. General variables

File: playbooks/common_config.yml

Notes:

• Public default passwords follow the Dbbot_<user>@8888 / Dbbot_<linux_user>@9999 convention. By default, fcs_allow_dbbot_default_passwd: false, so playbooks block those defaults in pre_tasks.
• The current default for fcs_mysql_use_jemalloc is false, which means the system allocator remains the default behavior.
• When fcs_mysql_use_jemalloc: true, dbbot first tries the OS repository package. It only falls back to the bundled legacy RPM if you explicitly set fcs_mysql_allow_bundled_jemalloc_fallback: true.
• mysql_binlog_format is configurable in the common file, but mgr.yml still requires row.
• fcs_run_post_deploy_checks is enabled by default. To temporarily skip post-deploy acceptance checks, pass -e fcs_run_post_deploy_checks=false explicitly.
• Automatic acceptance checks currently cover single_node.yml, master_slave.yml, mgr.yml, innodb_cluster.yml, innodb_cluster_router.yml, mha_go.yml, mha.yml, exporter installation entry playbooks, and unsafe_uninstall.yml. Backup and restore entry playbooks are not covered yet.
• Primary-replica post-deploy checks require zero replication lag by default. Use dbbot_post_check_replication_max_lag_seconds only when you need to temporarily relax that acceptance threshold.
• MySQL server package metadata is resolved from dbbotctl support after the target OS is detected. Use dbbotctl support packages to inspect the package name, download URL, and checksum for a version/OS pair.
• MySQL 9.7.x is not supported on the CentOS/RHEL 7 family; use MySQL 8.4.x on those systems.

2. Directory and package variables

File: playbooks/advanced_config.yml

Recommendations:

• Only change directory variables when you need a custom directory layout or a special restore path. Package metadata should normally come from dbbotctl support; for offline deployment, place the package with the support matrix file name under mysql_packages_dir.
• To temporarily test a MySQL Server package that is not in the support matrix, explicitly set fcs_allow_custom_mysql_package: true and set mysql_custom_package in advanced_config.yml. This applies to every entry that deploys MySQL Server, not only standalone deployment. It only overrides the Server package name; mysql_version, target OS, topology support checks, and MySQL Shell / Router package names still come from the support matrix.
• The cleanup scope of unsafe_uninstall.yml also depends on these directory variables. With the current default layout, it removes both the instance data and log directories, but keeps the instance my.cnf.

3. Primary-replica, legacy MHA, and MHA-Go variables

Files:

• playbooks/vars/var_master_slave.yml
• playbooks/vars/var_mha.yml
• playbooks/vars/var_mha_go.yml

Notes:

• master_ip and slave_ips must match the hosts in the inventory.
• Legacy Perl MHA still expects manager_ip on a replica node and not equal to master_ip.
• MHA-Go allows manager_ip to be either master_ip or a member of slave_ips; its current default is master_ip.
• The actual variable name is slave_ips, not replica_ips.
• The default net_work_interface value is only an example interface name. Before enabling legacy MHA VIP or the MHA-Go VIP writer endpoint, confirm the real interface with ip route or ip addr. Sample environments using the dbbot 192.168.161.* test inventory usually use enp1s0, but the real interface depends on the active test profile.

4. MGR variables

File: playbooks/vars/var_mgr.yml

Notes:

• greatsql_* variables only apply when db_type: greatsql.
• Override greatsql_net_work_interface with the real interface name. Sample environments using the dbbot 192.168.161.* test inventory usually use enp1s0, but the real interface depends on the active test profile.
• mgr.yml deploys single-primary mode by default.

5. InnoDB Cluster and Router variables

Files:

• playbooks/vars/var_innodb_cluster.yml
• playbooks/vars/var_innodb_cluster_router.yml

InnoDB Cluster variables:

Router variables:

Notes:

• router_ha_nodes only matters when router_enable_ha: true.
• Override router_net_work_interface with the real interface name on the Router nodes. Sample environments using the dbbot 192.168.161.* test inventory usually use enp1s0, but the real interface depends on the active test profile.
• With router_linux_glibc_tag: auto, Router 9.7.x uses glibc2.28 and Router 8.4.x uses glibc2.17; set the glibc tag explicitly when you need a fixed package name.
• By default, router_ports.http.port is 8443, and mysqlrouter_exporter reads Router metrics from this REST API endpoint.

6. Exporter variables

Files:

• playbooks/vars/var_node_exporter_install.yml
• playbooks/vars/var_mysqld_exporter_install.yml
• playbooks/vars/var_router_exporter_install.yml

Auto port rule:

• When mysqld_exporter_port: auto, the port is calculated as 9104 + mysql_port - 3306.
• When mysqld_exporter_topology: auto, dbbot checks performance_schema.replication_group_members; if members exist it resolves to mgr, otherwise it resolves to ms.
• mysqlrouter_exporter depends on the Router REST API by default, so if you change the Router HTTP port or bind address, update the exporter settings as well.
• mysqlrouter_exporter_install_type: dbbot uses the bundled binary from the dbbot release package, while package downloads the standalone project’s release archive from mysqlrouter_exporter_url.

6.1 Dependency quick reference

Router chain:

• innodb_cluster.yml
• innodb_cluster_router.yml
• router_exporter_install.yml
• dbbotctl exporter register -t router
• router_unsafe_uninstall.yml when Router cleanup is required

MHA chain:

• mha.yml
• mha_unsafe_uninstall.yml when legacy MHA and the MySQL instance must be cleaned up together
• mha_go.yml
• mha_go_unsafe_uninstall.yml when MHA-Go and the MySQL instance must be cleaned up together

MySQL exporter chain:

• single_node.yml / master_slave.yml / mgr.yml
• node_exporter_install.yml
• mysqld_exporter_install.yml
• dbbotctl exporter register -t node
• dbbotctl exporter register -t mysql

7. MySQL 8.4 clone backup variables

File: playbooks/vars/var_backup_script_8.4.yml

Notes:

• When backup_scope=selected, backup_preferred_host must be set explicitly.
• backup_cron is validated as a five-field cron expression in pre_tasks.

8. MySQL 8.4 PITR restore variables

File: playbooks/vars/var_restore_pitr_8.4.yml

Restore constraints:

1. When enable_pitr: true, set exactly one of pitr_target_time or pitr_target_gtid.
2. restore_pitr_8.4.yml only supports db_type: mysql and mysql_version: 8.4.x.

9. Notes for the 5.7 backup script and uninstall

backup_script.yml and unsafe_uninstall.yml do not have dedicated vars/*.yml files. They mainly depend on the following configuration sources:

• The MySQL 5.7 backup script relies on common_config.yml and advanced_config.yml
• Whether the backup user is created automatically is controlled by fcs_backup_script_create_backup_user
• The delete scope of unsafe_uninstall.yml follows datadir, tmpdir, binlog_dir, relaylog_dir, and redolog_dir from advanced_config.yml
• The target instance for uninstall is determined by the currently effective mysql_port in common_config.yml

Additional notes:

• backup_script.yml is currently for MySQL 5.7, and its retention behavior is mainly defined inside the role template rather than a public variable file.
• unsafe_uninstall.yml keeps the software base directory, Linux user, and my.cnf, but its delete scope still follows advanced_config.yml. With the current default layout, it removes both the instance data and log directories. It still requires manual confirmation before execution.

10. Recommended reading order

1. MySQL Primary-Replica Deployment Quick Start
2. MySQL Custom Directory Layout
3. MySQL 8.4 Backup and Restore
4. MySQL InnoDB Cluster Deployment Guide
5. MySQL MHA Deployment Guide