Mastering MHA Core Parameters: Complete Guide to MySQL HA Configuration

6.1 Parameter Matrix Diagram

6.2 Core Parameter Details

Local Scope

Parameters defined under each [server_xxx] section in the app.cnf configuration file apply to a specific server.

App Scope

Parameters for each {master,slave} pair are defined in the [server_default] section of app.cnf.

Global Scope

Parameters that affect all {master,slave} pairs are defined in the global configuration file masterha_default.cnf under [server_default].

hostname

The target MySQL server's hostname or IP address. Must be set in the [server_xxx] section of app.cnf.

ssh_connection_timeout

Supported from MHA 0.54, default is 5 seconds (previously hard‑coded).

ssh_options

Additional SSH command options, supported from MHA 0.53.

candidate_master

If set to 1, the server has a higher chance to be elected as the new master (requires binlog enabled and no large delay). When multiple servers have candidate_master=1, election follows the order they appear in the configuration.

no_master

When set to 1, the server will never become the new master; if no master can be elected, MHA exits.

ignore_fail

By default, MHA stops failover if a slave has problems (e.g., MySQL/SSH connection failure, SQL thread stopped). Setting ignore_fail=1 prevents the manager from stopping.

skip_init_ssh_check

Skip the initial SSH connectivity check.

skip_reset_slave

Supported from MHA 0.56; when set, the manager does not execute RESET SLAVE ALL after failover.

user / password / repl_user / repl_password / ssh_user

Authentication details:

user : MySQL username (default root).

password : Password for the MySQL user.

repl_user : Username for the replication thread.

repl_password : Password for the replication thread (required when the original master becomes a slave).

ssh_user : Operating‑system user for manager/node actions; default is the current OS user of the MHA manager.

disable_log_bin

When applying relay‑log differences on a slave, this option prevents writing to the binlog.

remote_workdir

Working directory for MHA nodes; default /var/tmp.

master_binlog_dir

Directory on the master where binlogs are stored; default /var/lib/mysql and /var/log/mysql.

manager_workdir

Working directory for the MHA manager; default /var/tmp.

manager_log

Log directory for the manager; if not set, logs are sent to standard output/error.

check_repl_delay

By default, if a slave lags behind the master by ~100 MB of relay logs, MHA will not select it as the new master. Setting check_repl_delay=0 disables this check, useful for forcing a specific candidate master.

check_repl_filter

If replication filter rules differ, MHA stops monitoring and failover. Setting check_repl_filter=0 ignores the difference (use with caution).

ping_interval

Interval (seconds) for the manager to ping the master. Default is 3 seconds; three consecutive failures mark the master as down. Connection‑related errors like “too many connections” or authentication failures are ignored.

secondary_check_script

Allows using multiple remote hosts to verify master availability. Example configuration:

secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2

The script runs from each remote host; if at least one route succeeds while another fails, MHA treats the master as down.

master_ip_failover_script

Custom script executed during failover to handle virtual IP movement. Example path:

master_ip_failover_script = /usr/local/sample/bin/master_ip_failover

The manager calls this script three times:

Check phase ( --command=status).

Current master shutdown phase ( --command=stop or stopssh).

New master activation phase ( --command=start).

Each call receives parameters such as --ssh_user, --orig_master_host, --new_master_host, etc.

master_ip_online_changes_script

Similar to master_ip_failover_script but used for online master switches rather than failover.

Shutdown and Reporting Scripts

Parameters like shutdown_script, report_script, and init_conf_load_script are deprecated (shown with strikethrough) and have no effect by default.

Flushing and Write Lock

During the write‑freeze phase, MHA executes FLUSH TABLES WITH READ LOCK on the old master to ensure a graceful switch with no writes. After the new master is activated, custom actions (e.g., creating users, setting read_only=0) can be performed via the failover scripts.