Detailed description of MHA parameters of the MySQL high-availability component. Description of MHA parameters of MySQL high availability component MHA is currently a relatively mature solution for MySQL high availability. It was developed by the Japanese, is an excellent set of MHA parameters for MySQL high availability components in a MySQL high availability environment
MHA is currently a relatively mature solution for MySQL high availability. it is developed by the Japanese and is a set of excellent high-availability software for failover and master-slave improvement in the MySQL high availability environment. MHA provides a series of configuration parameters to deeply understand the specific meaning of each parameter. it is very important to optimize the configuration and make rational use of MHA. many high availability parameters are also implemented by reasonably configuring some parameters. Next we will introduce in detail some parameters that may be used in the MHA process ~
Local: refers to the interior of each configuration block. The Local function parameters must be placed under the [server_xxx] block.
App: parameters apply to master/slave. these parameters must be configured under the [server_default] block.
Global: for master/slave, Global-level parameters are used to manage multiple groups of master/slave structures, and some parameters can be managed uniformly.
Hostname: 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.
Example and description of whether the parameter name must be the default value of the scope
Hostname Yes Local Only-hostname = mysql_server1, hostname = 192.168.0.1, etc
Ip: 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:
Example and description of whether the parameter name must be the default value of the scope
Ip No Local Only obtains ip = 192.168.1.3 through gethostbyname ($ hostname)
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:
Example and description of whether the parameter name must be the default value of the scope
Port No Local/App/Glbal 3306 port = 3306
Ssh_host: MHA needs to use the hostname or IP address of 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:
Example and description of whether the parameter name must be the default value of the scope
Ssh_host No Local Only and hostname are the same ssh_host = mysql_server1, ssh_host = 192.168.0.1, etc
Ssh_ip: (supported since MHA 0.53. The default value is gethostname ($ ssh_host.
For example:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
Ssh_connection_timeout No Local/App/Global 5 ssh_connect_timeout = 5
Ssh_options: (supported after MHA 0.53) add support parameters for the ssh command line, such as support for keys with special file names.
For example:
Example and description of whether the parameter name must be the default value of the scope
Ssh_options No Local/App/Global "" empty ssh_options = "-I/root/. ssh/id_dsa2 ″
Candidate_master: you may have different plans for the same group of slave, some of which are expected to be upgraded to a new Master (for example: raid1 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:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
No_master No Local Only 0 no_master = 1
Ignore_fail) (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:
Example and description of whether the parameter name must be the default value of the scope
Ignore_fail No Local Only 0 ignore_fail = 1
Skip_init_ssh_check: The ssh check is skipped when MHA manager is started.
For example:
Example and description of whether the parameter name must be the default value of the scope
Skip_init_ssh_check No Local Only 0 skip_init_ssh_check = 1
Skip_reset_slave: (supported from MHA 0.56) after the Master fails over, the new master executes reset slave (ALL ).
For example:
Example and description of whether the parameter name must be the default value of the scope
Skip_reset_slave No Local/App/Global 0 skip_reset_slave = 1
User: the user name used to manage MySQL. It is best to use the root user because it needs to execute: stop slave; change master to, reset slave. default: root
For example:
Example and description of whether the parameter name must be the default value of the scope
User No Local/App/Global root user = mysql_root
Password: the password of the MySQL administrator. The default value is null.
For example:
Example and description of whether the parameter name must be the default value of the scope
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 user. 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:
Example and description of whether the parameter name must be the default value of the scope
Repl_user No Local/App/Global From show slave status repl_user = repl
Repl_password: password of repl_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:
Example and description of whether the parameter name must be the default value of the scope
Repl_password No Local/App/Global repl_password = replpas
Disable_log_bin: If 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:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
Ssh_user No Local/App/Global Current system user ssh_user = root
Remote_workdir: 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:
Example and description of whether the parameter name must be the default value of the scope
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 node. 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:
Example and description of whether the parameter name must be the default value of the scope
Master_binlog_dir No Local/App/Gobal/var/lib/mysql master_binlog_dir =/data/mysql1,/data/mysql2
Log_level: Set the LOG level of the MHA manager record. 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:
Example and description of whether the parameter name must be the default value of the scope
Log_level No App/Global info log_level = debug
Manager_workdir: Used to specify the full path of the state file generated by mha manager. If no value is set, the default value is/var/tmp.
For example:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
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 the 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:
Example and description of whether the parameter name must be the default value of the scope
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 and does not perform monitoring or 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:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
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 it loses three trials with the master, MHA Manager will think that the MySQL Master is 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:
Example and description of whether the parameter name must be the default value of the scope
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:
Example and description of whether the parameter name must be the default value of the scope
Ping_type No App/Global SELECT ping_type = CONNECT
Secondary_check_script: generally, we recommend that you use more machines on the network with 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.
-User = (the SSH user name used on the remote machine. The ssh_user value will be used)
-Master_host = (master's hostname)
-Master_ip = (master IP address)
-Master_port = (master port number)
Masterha_secondary_check: The script depends on Perl's IO: Socket: INET (this module is supported by Perl 5.6.0 by default ). Masterha_secondary_check needs to be connected to a remote machine through ssh, so the manager needs to establish public key trust on the remote machine. In addition, masterha_secondary_check establishes a TCP connection with the Master to test whether the Master is alive. Therefore, the max_connections set in mysql does not work. However, after each TCP connection is successful, the value of Aborted_connects of MySQL is increased by 1.
For example:
Example and description of whether the parameter name must be the default value of the scope
Secondary_check_script No App/Global null secondary_check_script = masterha_secondary_check-s remote_dc1-s remote_dc2
Master_ip_failover_script:
For example:
Example and description of whether the parameter name must be the default value of the scope
Master_ip_failover_script No App/Global null master_ip_failover_script =/usr/local/custom_script/master_ip_failover
Master_ip_online_changes_script: this parameter is a bit similar to master_ip_failover_script. However, this parameter is not used for master failover and only used for online master failover.
The process of freezing Master write:
-Command = stop or stopssh
-Orig_master_host = (host name of the current master)
-Orig_master_ip = (IP address of the current master)
-Orig_master_port = (port number of the current master)
-Orig_master_user = (current master user)
-Orig_master_password = (username of the current master)
-Orig_master_ssh_user = (supported from 0.56, the ssh user name of the current master)
-Orig_master_is_new_slave = (from 0.56, whether to change the original Master to a new slave)
The new Master accepts the write process:
-Command = start
-Orig_master_host = (machine name of the original master)
-Orig_master_ip = (ip address of the original master)
-Orig_master_port = (original master port number)
-New_master_host = (machine name of the new master)
-New_master_ip = (ip address of the new master)
-New_master_port = (New master port number)
-New_master_user = (username on the new master)
-New_master_password = (username and password on the new master)
-New_master_ssh_user = (supported from 0.56, ssh users on the new master)
MHA will execute FlUSH tables with read lock on the Master during the switching process of frozen write, and no write will be performed in this elegant switching process. When the new Master starts to authorize write, you can do the same thing as master_ip_failover_script. For example, create users and permissions, execute set global read_only = 0, and update the database route table principal. If the exit code of the script execution is not 0 or 10, the MHA Manager will exit abnormally and the concurrency will not continue the master switch.
This parameter is null by default, so MHA Manager does not do anything by default.
You can change it in (MHA Manager package)/samples/scripts/master_ip_online_change. Find the example script. The example script is included in the MHA Manager source file or the GitHub branch.
For example:
Example and description of whether the parameter name must be the default value of the scope
Master_ip_online_change_script No App/Global null master_ip_online_change_script =/usr/local/custom_script/master_ip_online_change
Shutdown_script:
For example:
Example and description of whether the parameter name must be the default value of the scope
Shutdown_script No App/Global null shutdown_script =/usr/local/custom_script/master_shutdown
Report_script:
After the Master node fails, you may want to send a report (such as email) to report the switchover or errors. Report_script can complete this task. MHA Manager can be used with the following parameters:
-Orig_master_host = (name of the dead master machine)
-New_master_host = (new master machine name)
-New_slave_hosts = (list of new server names separated by commas)
-Subject = (email name)
-Body = (body)
By default, these parameters are null. Therefore, MHA Manager does nothing by default.
You can find the example script in (MHA Manager package)/samples/scripts/send_report. The example script is included in the MHA Manager source file or the GitHub branch.
For example:
Example and description of whether the parameter name must be the default value of the scope
Report_script No App/Global null report_script =/usr/local/custom_script/report
Init_conf_load_script: this parameter is used to avoid setting plaintext in the configuration file (for example, password-related ). Only return values such as "name = value. This can be used to override some values in the global configuration. An example script is as follows.
#! /Usr/bin/perl
Print "password = $ ROOT_PASS \ n ";
Print "repl_password = $ REPL_PASS \ n ";
For example:
Example and description of whether the parameter name must be the default value of the scope
Init_conf_load_script No App/Global null report_script =/usr/local/custom_script/init_conf_loader
Currently, mongomha is a relatively mature solution for MySQL high availability. it is developed by the Japanese and is a set of excellent MySQL high availability environments...
