MHA parameter list _ MySQL

MHA parameter list details Global: Global parameters apply to master/slave. Global parameters are used to manage multiple groups of master/slave structures, and some parameters can be managed uniformly.
Hostname

Configure the machine name or IP address of the MySQL server. this configuration item is required and can only be configured under the [server_xxx] block.
For example:

Parameter name	Required?	Scope	Default value	Example and description
Hostname	Yes	Local Only	-	Hostname = mysql_server1, hostname = 192.168.0.1, etc

Ip

The IP address of the MySQL server. The default value is gethostname ($ hostname. By default, this parameter is not required. MHA can be automatically obtained through hostname, and MHA can connect to the MySQL server through IP addresses and SSH connections.
For example:

Parameter name	Required?	Scope	Default value	Example and description
Ip	No	Local Only	Obtained through gethostbyname ($ hostname)	Ip = 192.168.1.3

Port

The port number of the MySQL instance. The default value is 3306. MHA uses the IP address and port number to connect to MySQL.
For example:

Parameter name	Required?	Scope	Default value	Example and description
Port	No	Local/App/Glbal	3306	Port = 3306

Ssh_host

(Supported since MHA 0.53) MHA wants to use the hostname or IP address on the MySQL target server over ssh. This parameter is mainly used in environments where multiple VLANs are used. Ssh is not allowed by default for security reasons. By default, this parameter is the same as the hostname parameter.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Ssh_host	No	Local Only	Same as hostname	Ssh_host = mysql_server1, ssh_host = 192.168.0.1, etc

Ssh_ip

(Supported since MHA 0.53) and ssh_host have the same effect. The default value is gethostname ($ ssh_host.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Ssh_ip	No	Local Only	Gethostbyname ($ ssh_host)	Ssh_ip = 192.168.1.3

Ssh_port

(Supported since MHA 0.53) the port number used by SSH. the default value is 22.
For example:

Parameter name	Required?	Scope	Default value	Example and description
Ssh_port	No	Local/App/Global	22	Ssh_port = 22

Ssh_connection_timeout

(Supported after MHA 0.54) the default value is 5 seconds. Before this parameter is added, the ssh timeout value is written to death.
For example:

Parameter name	Required?	Scope	Default value	Example and description
Ssh_connection_timeout	No	Local/App/Global	5	Ssh_connect_timeout = 5

Ssh_options

(Supported after MHA 0.53) add support parameters for ssh command lines, such as support for keys with special file names.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Ssh_options	No	Local/App/Global	"" Blank	Ssh_options = "-I/root/. ssh/id_dsa2 ″

Candidate_master

You may have different plans for the same group of slave, some of which hope to be upgraded to a new Master when the Master fails (for example: raid1 + 1 slave is more suitable for Master than Raid0 slave)

This parameter is used when candidate_master = 1 is designed, the server has a higher priority to be upgraded to the new master (also available: enable binlog, no replication delay ). Therefore, when candidate_master = 1 is set, the machine will inevitably become a new master when the master fails. However, this is a useful parameter for setting priority.

If caddidate_master is set to 1 for multiple machines, the priority policy depends on the block name ([server_xxx]). [server_1] the priority is higher than [server_2].

For example:

Parameter name	Required?	Scope	Default value	Example and description
Candidate_master	No	Local Only	0	Candidate_mast = 1

No_master

When no_master = 1 is set, this server will never be upgraded to a new master. this parameter is useful for machines that never expect to become masters. For example, you may need to set no_master = 1 on a machine using raid0 or you want to run a slave in a remote idc. note: If MHA is not the machine that can become a new master, it will exit directly and stop monitoring and master failover at the same time.

For example:

Parameter name	Required?	Scope	Default value	Example and description
No_master	No	Local Only	0	No_master = 1

Ignore_fail

By default, MHA manager does not fail when slave is faulty (connection via SSH/MySQL is no longer allowed, or an error occurs when SQL Thread is stopped. for other reasons) (MHA manager also exits when there is no slave ). However, in some cases, you want to switch between slave and slave. Therefore, when ignore_fail = 1 is set, MHA will perform failover when all machines have problems. The default value is 0.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Ignore_fail	No	Local Only	0	Ignore_fail = 1

# Skip_init_ssh_check #
Skip the ssh check when MHA manager is started.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Skip_init_ssh_check	No	Local Only	0	Skip_init_ssh_check = 1

Skip_reset_slave

(Supported from MHA 0.56) after the Master failover, the new master executes reset slave (ALL ).

For example:

Parameter name	Required?	Scope	Default value	Example and description
Skip_reset_slave	No	Local/App/Global	0	Skip_reset_slave = 1

User

The username used to manage MySQL. This requires the root user, because it needs to execute: stop slave; change master to, reset slave. default: root

For example:

Parameter name	Required?	Scope	Default value	Example and description
User	No	Local/App/Global	Root	User = mysql_root

Password

The password of the MySQL administrator. The default value is null.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Password	No	Local/App/Global	Empty	Password = rootpass

Repl_user

MySQL is used for replication. it is also used TO generate a change master to each slave. This user must have the replication slave permission on the new Master. By default, repl_user will run the show slave status command on the machine that becomes the master node in the future.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Repl_user	No	Local/App/Global	From show slave status	Repl_user = repl

Repl_password

Password of the repl_user user in MySQL. The default password is used for current replication. When you use online_master_switch, when you use-orig_master_is_new_slave (the original Master becomes a new Master's slave), if you do not enable synchronization without repl_password, it will fail. Because the username and password used for replication on the current master are empty (MHA does not carry the copy password when performing change Master to on the original master, although the password for replication is set on other slave instances)

For example:

Parameter name	Required?	Scope	Default value	Example and description
Repl_password	No	Local/App/Global	Password used for current copy	Repl_password = replpas

Disable_log_bin

When this parameter is set, binary logs are not generated when the slave application returns a different relay log. Internal implementation is implemented through disable-log-bin of mysqlbinlog.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Disable_log_bin	No	Local/App/Global	0	Disable_log_bin = 1

Master_pid_file

Specify the MySQL pid file. This parameter is useful when running multiple MySQL service processes on a server.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Master_pid_file	No	Local/App/Global	-	Master_pid_file =/var/lib/mysql/master1.pid

Ssh_user

MHA Mananger, a user on the MHA node system. This account must have the execution permission (Manager-> MySQL) on the remote machine and copy the different relay-log (MySQL-> MySQL) between slave members)

This user must have the permission to read the binary/relay log and relay_log.info of MySQL, and write permission on the remote_workdir directory of remote MySQL.

This user must also be able to directly ssh to the remote server. we recommend that you use the ssh pbulic key. Generally, the ssh_user is also the user who runs the manager.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Ssh_user	No	Local/App/Global	Current system user	Ssh_user = root

Remote_workdir

The full path name of the working directory on the MHA node. If no MHA node exists, MHA Node is automatically created. if creation is not allowed, MHA node exits unexpectedly. Check whether the space is available on MHA manager or MHA node. The default value is remote_workdir "/var/tmp"

For example:

Parameter name	Required?	Scope	Default value	Example and description
Remote_workdir	No	Local/App/Global	/Var/tmp	Remote_workdir =/var/log/masterha/app1

Master_binlog_dir

Full path for storing binary logs on the master. This parameter is used to connect to the mysql server through ssh when mysql on the master node is dead and locate the binary log event. This parameter can be used to locate the binary log storage location after the master process is dead.

General: master_binlog_dir is "/var/lib/mysql/,/var/log/mysql ". "/var/lib/mysql/" is the storage location of most system releases, and "/var/log/mysql" is the storage location of ubuntu releases. You can also set multiple storage locations to be separated by commas.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Master_binlog_dir	No	Local/App/Gobal	/Var/lib/mysql	Master_binlog_dir =/data/mysql1,/data/mysql2

Log_level

Set the MHA manager record LOG level. The default value is the info level and is suitable for most cases. You can also set it to debug/info/warning/error.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Log_level	No	App/Global	Info	Log_level = debug

Manager_workdir

Specifies the full path of the status file generated by the mha manager. If no value is set, the default value is/var/tmp.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Manager_workdir	No	App	/Var/tmp	Manager_workdir =/var/log/masterha

Manager_log

Specifies the file name log file of the absolute path of the mha manager. If MHA Manager is not set, it is printed to STDOUT/STDERR. When manual failover (interactive mode switchover) is performed, MHA Manager directly outputs logs to STDOUT/STDERR regardless of manager_log settings.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Manager_log	No	App	STDERR	Manager_log =/var/log/masterha/app1.log

Check_repl_delay

By default, when a slave synchronization latency exceeds 100 M relay log (more than 100 M relay log needs to be applied), MHA does not select this slave as the new master during failover, because recovery takes a long time. when check_repl_delay = 0 is set, MHA ignores the synchronization delay on the selected slave. This option is particularly useful when candidate_master = 1 is set to expect this machine to become a master.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Check_repl_delay	No	App/Golbal	1	Check_repl_delay = 0

Check_repl_filter

By default, when the master and slave set different binary log/replication filtering rules, MHA directly reports errors without monitoring and failover. These will cause some unexpected errors "Table not exists ". If you confirm 100% that different filtering rules will not cause errors in recovery, set check_repl_filter = 0. Note: When check_repl_filter = 0 is used, MHA does not check the relay logs of different filtering rules in the application. Therefore, the error "Table not exists" may occur. Please be careful when Setting this parameter.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Check_repl_filter	No	App/Global	1	Check_repl_filter = 0

Latest_priority

By default, the closest slave to the Master (one slave obtains the most binlog event from the Master) is the most priority to become the new master. If you want to control the switch policy (for example, select host2 first, if not, select host3; host3 if not, select host4 ...) Set latest_priority to 0.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Latest_priority	No	App/Global	1	Latest_priority = 0

Multi_tier_slave

Multi-layer replication is supported starting from MHA 0.52. By default, layer-3 or multi-layer replication configurations are not supported. If host2 is copied from host1, host3 is copied from host2. In the default configuration, host {1, 2, 3} cannot be written. because this is a layer-3 replication, MHA Manager will stop reporting errors. When multi_tier_slave is set, MHA Manager will not report an error and stop in layer-3 replication. However, the third-tier machine is ignored. That is, if host1 fails, host2 will become a new master, and host3 will still be copied from host2.

This parameter is supported in versions later than MHA Manager 0.52.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Muli_tier_slave	No	App/Global	0	Multi_tier_slave = 1

Ping_interval

This parameter sets the time for MHA Manager to ping the master (execute some SQL statements). when the master is lost three times, MHA Manager considers the MySQL Master dead. That is to say, the maximum failover time is 4 ping_interval times. The default value is 3 seconds.

If MHA Manager receives a multi-connection error or authentication error when creating a connection with MySQL, the master will be suspended without retrying.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Ping_interval	No	App/Global	3	Ping_interval = 5

Ping_type

(Supported since MHA 0.53) by default, MHA manager and MySQL create a connection and execute "select 1" (ping_type = select) to check whether the master is healthy. However, in some cases, it is better to connect to/and then disconnect each detection, so that tcp errors can be perceived more quickly. Set ping_type = CONNECT. Pint_type = INSERT is also added after MHA 0.56.

For example:

Parameter name	Required?	Scope	Default value	Example and description
Ping_type	No	App/Global	SELECT	Ping_type = CONNECT

Secondary_check_script

Generally, we recommend that you use more machines on different routing policies to check whether the MySQL Master is alive. By default, only the MHA Manager checks whether the Master is alive through a route. This is not recommended. MHA can use the script configured by external secondary_check_script to check from multiple routing policies.

Secondary_check_script = masterha_secondary_check-s remote_host1-s remote_host2

Secondary_check_script is included in the MHA Manager release package. The built-in secondary_check_script in MHA works well in most cases, but it is not always usable.

In the preceding example, MHA Manager uses Manager-> (A)-> remote_host1-> (B)-> master_host and Manager-> (A)-remote_host2-> (B) -> master_host to check whether the MySQL master is alive. If A succeeds during the connection process and B fails, secondary _/check _/script returns 0 and considers the master to be dead, failover is performed. If A succeeds but the returned code is 2, MHA manager considers it A network problem and does not perform failover. If A succeeds, B succeeds, and masterha_secondary_check exits and returns: 3, MHA Manager considers the MySQL Master to be alive and does not perform failover.

Generally, remote_host1 and remote_host2 are in different CIDR blocks than MHA Manager and MySQL Server.

MHA will call the scripts declared by secondary_check_script and automatically include some parameters. Masterha_secondary_check is applicable in many scenarios, but you can also implement this program with more functions.