MySQL High-availability components MHA parameters
MHA is currently a relatively mature solution for MySQL high availability, developed by the Japanese, and is an excellent set of highly available software for failover and master-slave upgrading in MySQL high-availability environments. MHA provides a series of configuration parameters, in-depth understanding of the specific meaning of each parameter, it is important to optimize the configuration, reasonable use of MHA, and many high-availability is achieved through the rational configuration of some parameters. Let's take a detailed description of some of the parameters that may be used in the process of using MHA ~
Local: Refers to the inside of each configuration block. The parameters of the local function need to be placed under the [SERVER_XXX] Block
APP: Parameters acting on Master/slave, these parameters need to be configured under [Server_default] Blocks
Global: For Master/slave, global-level parameters are used to manage multiple sets of master/slave structures, and you can unify the management of some parameters.
Hostname: Configure the MySQL server's machine name or IP address, this configuration item is required, and can only be configured under the [SERVER_XXX] block.
Example of whether the parameter name must be scoped to the default value, and a description
Hostname Yes Local only–hostname=mysql_server1, hostname=192.168.0.1, etc
The IP address of the IP:MYSQL server. The default is obtained from GetHostName ($hostname). By default, this parameter is not configured, MHA can be automatically obtained through hostname, MHA connect MySQL server and SSH connection via IP address.
Such as:
Parameter name must scope default example and description
IP No Local only obtains ip=192.168.1.3 via gethostbyname ($hostname)
Port:mysql the port number to run. The default is 3306. MHA using IP and port numbers to connect to MySQL
Such as:
Parameter name must scope default example and description
Port No Local/app/glbal 3306 port=3306
Ssh_host:mha to SSH on the MySQL target server using hostname or IP address. This parameter is primarily used in environments where multiple VLANs are used. SSH is not allowed by default for security reasons. The default parameter is the same as hostname.
Such as:
Parameter name must scope default example and description
Ssh_host No Local only and hostname same ssh_host=mysql_server1, ssh_host=192.168.0.1, etc
SSH_IP: (Starting with support after MHA 0.53) and Ssh_host function the same. The default is GetHostName ($ssh _host) obtained.
Such as:
Parameter name must scope default example and description
Ssh_ip No Local only gethostbyname ($ssh _host) ssh_ip=192.168.1.3
Ssh_port: (Supported from MHA 0.53) the port number used by SSH, default is 22.
Such as:
Parameter name must scope default example and description
Ssh_port No Local/app/global ssh_port=22
Ssh_connection_timeout: (Supported from MHA 0.54) The default is 5 seconds. The SSH timeout was written dead before this parameter was added.
Such as:
Parameter name must scope default example and description
Ssh_connection_timeout No Local/app/global 5 ssh_connect_timeout=5
Ssh_options: (Supported from MHA 0.53) Add support parameters for SSH command line, such as support for key with special file name.
Such as:
Parameter name must scope default example and description
Ssh_options No local/app/global "" Empty ssh_options= "-i/root/.ssh/id_dsa2″
Candidate_master: You may have different plans for the same set of slave, and some of them will be promoted to the new master if the master fails (for example: Raid1 slave is better for master than Raid0 Slave)
The function of this parameter is when design Candidate_master = 1 o'clock, the server has a higher priority to the new master (also have: Open binlog, replication without delay). So when a machine with candidate_master = 1 is set, it must become the new master when the master fails. But this is a very useful setting for the precedence of a parameter.
If Caddidate_master = 1 is set for multiple machines, the precedence policy depends on the block name ([server_xxx]). [server_1] Superior title is higher than [server_2].
Such as:
Parameter name must scope default example and description
Candidate_master No Local only 0 candidate_mast=1
No_master
When a server with No_master = 1 is set, this server will never be promoted to the new master. This parameter is useful for machines that are never expected to be master. For example, you may need to set No_master = 1 on a machine that uses RAID0 or you want to run a slave in a remote IDC. Note: When there is no machine that can be the new master, MHA exits directly to stop monitoring and master failover.
Such as:
Parameter name must scope default example and description
No_master No Local only 0 no_master=1
Ignore_fail: By default, MHA Manager does not have a failure in the slave (the connection cannot be made through Ssh/mysql, or the SQL thread has stopped making an error. For other reasons), failover of master (MHA manager exits when no slave is present). In some cases, however, you expect to fail over if there is a problem with slave. So when ignore_fail = 1 o'clock is set, MHA will fail over at all times when the machine is in trouble. The default is 0.
Such as:
Parameter name must scope default example and description
Ignore_fail No Local only 0 ignore_fail=1
Skip_init_ssh_check: Skip SSH Check when MHA Manager starts.
Such as:
Parameter name must scope default example and description
Skip_init_ssh_check No Local only 0 skip_init_ssh_check=1
Skip_reset_slave:: (starting from MHA 0.56) after master failover, perform reset slave (all) on the new master.
Such as:
Parameter name must scope default example and description
Skip_reset_slave No Local/app/global 0 skip_reset_slave=1
User: The username used to manage MySQL. This is best used by the root user because it needs to be performed: Stop slave; Change master to, reset slave. Default: Root
Such as:
Parameter name must scope default example and description
User No Local/app/global Root user=mysql_root
Password:mysql the password of the administrative user. The default is empty
Such as:
Parameter name must scope default example and description
Password No local/app/global empty Password=rootpass
Repl_user:mysql is used for replication users, and is also used to generate change MASTER to each slave used by the user. This user must have replication slave permissions on the new master. By default, Repl_user runs show slave status on the machine that will become Master in the future.
Such as:
Parameter name must scope default example and description
Repl_user No local/app/global from show slave status Repl_user=repl
The password for the Repl_user user in the Repl_password:mysql. The default is the password used for the current replication. When you use Online_master_switch, when you use –orig_master_is_new_slave (the original master becomes a slave of the new master), failure to turn on synchronization without Repl_password will fail. Because the user name and password used for replication on the current master are empty (MHA does not have a copy password when it executes change master on the original master, although the copied password is set on the other slave)
Such as:
Parameter name must scope default example and description
Repl_password No local/app/global Password for current replication Repl_password=replpas
Disable_log_bin: When this parameter is set, the binary log is not generated when slave applies the difference relay log. The internal implementation is implemented through the Mysqlbinlog Disable-log-bin.
Such as:
Parameter name must scope default example and description
Disable_log_bin No Local/app/global 0 disable_log_bin=1
Master_pid_file: Specifies the pid file for MySQL. This parameter is useful when running multiple MySQL service processes on a single server.
Such as:
Parameter name must scope default example and description
Master_pid_file No Local/app/global–master_pid_file=/var/lib/mysql/master1.pid
Ssh_user:mha Mananger, the user on the MHA node system. This account needs to have execute permissions on the remote machine (MANAGER->MYSQL) to replicate the differences between slave members Relay-log (MYSQL->MYSQL)
This user must have read MySQL Binary/relay log and Relay_log.info permissions, and also need to write permissions on the Remote_workdir directory on the remote MySQL.
This user must also be able to ssh directly to the remote machine, and it is recommended to use SSH pbulic key. The general Ssh_user is also the user who runs the manager.
Such as:
Parameter name must scope default example and description
Ssh_user No Local/app/global currently used by the system user Ssh_user=root
The full path name of the working directory on REMOTE_WORKDIR:MHA node. If it does not exist, MHA node is automatically created and MHA node automatically exits if it is not allowed to create. Be aware that MHA Manager or MHA node needs to check if the space is available, so check this out. General default, Remote_workdir yes "/var/tmp"
Such as:
Parameter name must scope default example and description
Remote_workdir No local/app/global/var/tmp Remote_workdir=/var/log/masterha/app1
The full path to store binary logs on the master_binlog_dir:master. This parameter is used to connect to the MySQL server via ssh when MySQL is dead on master and find the need for binary log events. This parameter can be used to help the binary log storage location that cannot be found after the master process has died.
General: Master_binlog_dir is "/var/lib/mysql/,/var/log/mysql". "/var/lib/mysql/" is the location of most system distributions, and "/var/log/mysql" is where the Ubuntu release is stored. You can also set multiple storage locations separated by commas.
Such as:
Parameter name must scope default example and description
Master_binlog_dir No Local/app/gobal/var/lib/mysql MASTER_BINLOG_DIR=/DATA/MYSQL1,/DATA/MYSQL2
Log_level: Sets the level of Log MHA Manager records. The default is the info level and most of the cases are appropriate. The same can be set to: Debug/info/warning/error.
Such as:
Parameter name must scope default example and description
Log_level No App/global Info log_level=debug
Manager_workdir: Used to specify the full path of the MHA manager to produce related state files. If not set default is/var/tmp
Such as:
Parameter name must scope default example and description
Manager_workdir No app/var/tmp Manager_workdir=/var/log/masterha
Manager_log: Specifies the file name log file for the absolute path of the MHA manager. If not set MHA Manager will print to Stdout/stderr. When manually performing a failover (interactive mode toggle), MHA Manager ignores the Manager_log settings and outputs the log directly to Stdout/stderr.
Such as:
Parameter name must scope default example and description
Manager_log No App STDERR manager_log=/var/log/masterha/app1.log
Check_repl_delay: By default, when a slave synchronization delay exceeds 100M relay log (requires more than 100M relay log), MHA does not select this slave as the new master when doing a 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 in cases where the expectation of the Candidate_master = 1 Special statement is that the machine becomes master.
Such as:
Parameter name must scope default example and description
Check_repl_delay No App/golbal 1 check_repl_delay=0
Check_repl_filter: In the default situation, when Master and slave set different binary log/replication filtering rules, MHA Direct error will not be monitored and failover. These will result in some unexpected error "Table not exists". If you 100% confirm that different filtering rules will not cause errors in the recovery, set check_repl_filter=0. Note: When Check_repl_filter = 0 o'clock is used, MHA does not check the relay log in which the filter rule applies the difference, so "Table NOT exists" error may occur. When you have set this parameter please handle it carefully.
Such as:
Parameter name must scope default example and description
Check_repl_filter No App/global 1 check_repl_filter=0
Latest_priority: By default, the closest slave to master (a slave obtains the most Binlog event from master) is the most priority to become the new master. If you want to control the switching strategy (such as: First select Host2, if not, choose Host3;host3 not, choose Host4 ... Then set latest_priority = 0 to do it.
Such as:
Parameter name must scope default example and description
Latest_priority No App/global 1 latest_priority=0
Multi_tier_slave:
Starting with MHA 0.52, multilayer replication can be supported. Replication configurations of layer three or more are not supported by default. If: Host2 is copied from host1, Host3 is copied from Host2. Write host{1,2,3} is not supported in the default configuration because this is a three-tier replication and MHA Manager will stop the error. When the Multi_tier_slave is set, the MHA manager does not stop at the three-level replication error. But it ignores the third-tier machine. That is, if Host1 is hung, Host2 will become the new master,host3 or copy from Host2.
This parameter is supported at the beginning of the MHA Manager 0.52 version.
Such as:
Parameter name must scope default example and description
Muli_tier_slave No App/global 0 multi_tier_slave=1
Ping_interval: This parameter sets MHA manager how long to ping master (execute some SQL statements). When you lose and Master three times, MHA manager thinks MySQL master is dead. In other words, the maximum failover time is 4 ping_interval time, and the default is 3 seconds.
If MHA Manager receives multiple connection errors or authentication errors when creating a connection with MySQL, this does not retry and the master is considered dead.
Such as:
Parameter name must scope default example and description
Ping_interval No App/global 3 ping_interval=5
Ping_type: (Supported from MHA 0.53) by default, MHA Manager and MySQL create a connection to perform "Select 1″ (ping_type=select) to check if master is healthy. However, there are situations where it is better to connect/then disconnect each time, which makes the TCP error sense a bit faster. Set the Ping_type=connect on the line. The Pint_type=insert is also added after MHA 0.56.
Such as:
Parameter name must scope default example and description
Ping_type No App/global SELECT ping_type=connect
Secondary_check_script: In general, it is highly recommended that more machines on the network be used on different routing strategies to check if MySQL master survives. By default, only MHA manager checks to see if Master is alive through a route. This is also not recommended. The MHA can be checked from multiple routing strategies via an external SECONDARY_CHECK_SCRIPT-configured script.
Secondary_check_script = Masterha_secondary_check-s remote_host1-s remote_host2
The 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's not always possible to use this script.
In the example above, MHA Manager through Manager-> (a)->remote_host1-> (B)->master_host and Manager-> (a)-remote_host2-> (B)->master_host to check if MySQL master is alive. If through a can succeed during the connection process, through B all fails, Secondary_\check_\script returns 0, and the master is considered dead for failover. If you succeed with a, but the return code is: 2, then MHA Manager has a network problem and does not fail over. If a succeeds, B also succeeds, Masterha_secondary_check exits: 3 The MHA Manager does not fail over if it considers MySQL master to be alive.
Generally speaking, remote_host1 and Remote_host2 are in different network segments than MHA Manager and MySQL server.
MHA invokes the Secondary_check_script declared script and automatically takes some parameters. Masterha_secondary_check is applicable in many scenarios, but you can also self-implement this program with more features.
–user= (the SSH user name used on the remote machine.) The value of the Ssh_user will be used)
–master_host = (Master's hostname)
–MASTER_IP = (IP address of master)
–master_port = (port number of master)
Masterha_secondary_check: The script relies on Perl's io::socket::inet (Perl 5.6.0 is the default support included in this module). The Masterha_secondary_check needs to be connected to the remote machine via SSH, so the manager is required to establish public key trust on the remote machine. Another masterha_secondary_check is to test if Master is alive by establishing a TCP connection with master, so the max_connections of MySQL settings does not work. However, each time the TCP connection succeeds, the MySQL aborted_connects value will be added 1.
Such as:
Parameter name must scope default example and description
Secondary_check_script No app/global null secondary_check_script= masterha_secondary_check-s remote_dc1-s REMOTE_DC2
Master_ip_failover_script:
Such as:
Parameter name must scope default example and description
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 somewhat similar to master_ip_failover_script, but this parameter is not used for master failover, only the switch to master online is used.
To freeze the master write process:
–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 port number of the current master)
–orig_master_user = (user of current master)
–orig_master_password = (user name of current master)
–orig_master_ssh_user = (user name of SSH from 0.56 supported, 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 original master)
–orig_master_ip = (IP of original master)
–orig_master_port = (port number of original master)
–new_master_host = (machine name for new master)
–new_master_ip = (IP of the new master)
–new_master_port = (port number of the new master)
–new_master_user = (user name on new master)
–new_master_password = (user name and password on new master)
–new_master_ssh_user = (from 0.56 support, SSH user on new master)
MHA performs a flush TABLES with READ LOCK on master during a freeze-write switchover, and there is no writing in this graceful switchover process. In the new master, you can do the same thing as Master_ip_failover_script in the beginning of the authorization writing process. For example: Create user and permissions, execute set global read_only=0, Update Database routing table aulympic. If the script execution exit code is not 0 or ten, MHA manager exits concurrently and does not continue with the master switch.
The default parameter is empty, so MHA Manager does nothing by default.
Can be/samples/scripts/master_ip_online_change in (MHA Manager package). Find an example script. The example script is included in the MHA Manager source file or in the GitHub branch.
Such as:
Parameter name must scope default example and description
Master_ip_online_change_script No app/global null master_ip_online_change_script=/usr/local/custom_script/master_ Ip_online_change
Shutdown_script:
Such as:
Parameter name must scope default example and description
Shutdown_script No app/global null shutdown_script=/usr/local/custom_script/master_shutdown
Report_script:
After master failure, you may want to send a report (such as email) to report the switch completed or the error occurred. Report_script can do the job. MHA Manager can be used with the following parameters:
–orig_master_host = (dead Master machine name)
–new_master_host = (new master machine name)
–new_slave_hosts = (new list of slave machine names, separated by commas)
–subject = (mail name)
–body = (body)
These parameters are empty by default. So the default MHA manager doesn't do anything.
An example script can be found in the (MHA Manager package)/samples/scripts/send_report. The example script is included in the MHA Manager source file or in the GitHub branch.
Such as:
Parameter name must scope default example and description
Report_script No app/global null report_script=/usr/local/custom_script/report
Init_conf_load_script: This parameter is used to not want to set the plaintext in the configuration file (e.g., password related). Only values that return "Name=value" are used. This can be used to cover some of the 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";
Such as:
Parameter name must scope default example and description
Init_conf_load_script No app/global null report_script=/usr/local/custom_script/init_conf_loader
http://www.bkjia.com/PHPjc/1097747.html www.bkjia.com true http://www.bkjia.com/PHPjc/1097747.html techarticle MySQL High-availability Components MHA parameter Details MHA is currently a relatively mature solution in MySQL high availability, it developed by the Japanese, is a set of excellent as MySQL high Availability environment ...
