Shulou(Shulou.com)06/01 Report--

# # #

MHA parameter arrangement

19:58:41, September 17, 2014

Number of reads: 822

MHA profile parameters

Parameter Name

Required?

Parameter Scope

Default Value

Hostname

Yes

Local Only

-

Ip

No

Local Only

Gethostbyname ($hostname)

Port

No

Local/App/Global

3306

Ssh_host

No

Local Only

Same as hostname

Ssh_ip

No

Local Only

Gethostbyname ($ssh_host)

Ssh_port

No

Local/App/Global

twenty-two

Ssh_connection_timeout

No

Local/App/Global

five

Ssh_options

No

Local/App/Global

"(empty string)

Candidate_master

No

Local Only

0

No_master

No

Local Only

0

Ignore_fail

No

Local Only

0

Skip_init_ssh_check

No

Local Only

0

Skip_reset_slave

No

Local/App/Global

0

User

No

Local/App/Global

Root

Password

No

Local/App/Global

"(empty string)

Repl_user

No

Local/App/Global

Master_User value from SHOW SLAVE STATUS

Repl_password

No

Local/App/Global

(current replication password)

Disable_log_bin

No

Local/App/Global

0

Master_pid_file

No

Local/App/Global

"(empty string)

Ssh_user

No

Local/App/Global

Current OS user

Remote_workdir

No

Local/App/Global

/ var/tmp

Master_binlog_dir

No

Local/App/Global

/ var/lib/mysql

Log_level

No

App/Global

Info

Manager_workdir

No

App

/ var/tmp

Manager_log

No

App

STDERR

Check_repl_delay

No

App/Global

one

Check_repl_filter

No

App/Global

one

Latest_priority

No

App/Global

one

Multi_tier_slave

No

App/Global

0

Ping_interval

No

App/Global

three

Ping_type

No

App/Global

SELECT

Secondary_check_script

No

App/Global

Null

Master_ip_failover_script

No

App/Global

Null

Master_ip_online_change_script

No

App/Global

Null

Shutdown_script

No

App/Global

Null

Report_script

No

App/Global

Null

Init_conf_load_script

No

App/Global

Null

Local Scope: a parameter that applies to a single server range. The local scope parameter needs to be set under the [server_xxx] block in the application configuration file.

App Scope: parameters for each set of {master, slaves}. These parameters need to be set under the [server_default] block of the application configuration file.

Global Scope: parameters for all {master, slaves} groups. Global-scoped parameters are useful only when using a single manager server to manage multiple groups of {master, slaves}. These parameters need to be set in the global configuration file.

1.1 hostname

The Hostname or IP address of the MySQL server. This parameter is mandatory and must be configured under the [server_xxx] block in the applicationconfiguration file.

1.2 ip

The IP address of the MySQL server. The default value is gethostbyname ($hostname).. MHA Manager and MHA Node internally use this IP address to connect through MYSQL and SSH. You usually do not need to configure this parameter because it is automatically resolved through the hostname parameter.

1.3 port

The port number of the MySQL server. The default is 3306. MHA connects to the MySQL server through the IP address and port.

1.4 ssh_host

(supported from .53) the Hostname or IP address of the MySQL server used by SSH. This parameter (and the ssh_port parameter) is useful when using a multi-VLAN configuration. The default is the same as hostname.

1.5 ssh_ip

(supported from .53) the IP address of the MySQL server used through SSH. The default value is gethostbyname ($ssh_host).

1.6 ssh_port

(supported from .53) the port number of the MySQL server connected through SSH. The default is 22.

1.7 ssh_connection_timeout

(supported from 0.54) the default is 5 seconds. Before adding this parameter, the timeout is fixed and can only be changed in the code.

1.8 ssh_options

(supported from .53 onwards) additional options for the SSH command line.

1.9 candidate_master

Slaves may use different types of machines and need to upgrade the most reliable machine as new master. (for example: improve the slave of RAID1+0, not the slaves of RAID0).

By setting candidate_master to 1, as long as the server meets the conditions to become a new master, the server will first become a master (for example, when binlog is enabled, the delay is not obvious, etc.), so candidate_master=1 does not mean that the specified host will always become a new master after the current master is hung up, but is used to set the priority.

If candidate_master=1 is set on multiple servers, the priority is based on the order of the block name ([server_xxx]). [server_1] priority is higher than [server_2].

1.10 no_master

Set no_master=1 on the target server, which will not become a new master. This parameter is useful if there are some servers that should not be new master. For example, if you run salve on an unreliable machine (RAID0), or if you run slave on a remote data center, you may need to set up no_master=1. If there is no slave available, new master,MHA will exit and there will be no monitoring or failover.

1.11 ignore_fail

By default, if any slave runs wrong (the MySQL,SQL thread cannot be connected through SSH, the error stops waiting), MHA Manager does not fail over. However, in some cases, if a particular slave server goes wrong and you still want to continue the failover, you can set ignore_fail=1 on the specified server, and MHA will continue to fail over even if those servers fail. By default, the parameter value is 0.

1.12 skip_init_ssh_check

Skip the SSH connection when initializing.

1.13 skip_reset_slave

Skip execution of RESET SLAVE (ALL) after master transfer.

1.14 user

Connect to the administrative account of the MySQL server. This parameter should be root because some administrative commands, such as STOP SLAVE,CHANGE MASTER,RESET SLAVE, are executed. The default is root.

1.15 password

The MySQL password of the above "user" user. The default is empty.

1.16 repl_user

Execute CHANGE MASTER TO master_user on each slave.. The replication user name used when the. The user needs to have REPLICATIONSLAVE permissions on master. By default, the value of the column Master_User in SHOW SLAVE STATUS on new master (currently or slave) is used.

1.17 repl_password

The MySQL password of the above "repl_user" user. By default, it is the current replication password. If you run onlinemaster switch and specify the-- orig_master_is_new_slave (meaning that the current master will be the slave of new master), if you do not specify repl_password, enabling slave will fail because the replication password is empty by default on the current master (although the replication password is set on other slaves, MHA does not specify the replication password when executing change master on the current master).

1.18 disable_log_bin

When this parameter is enabled, slaves does not generate binary logs when differential relay logs is applied on slaves. MHA passes-- disable-log-bin to the mysqlbinlog command.

1.19 master_pid_file

Set up the pid file for master. This parameter is valid when running multiple MySQL instances on a single server. Refer to the shutdown_script parameter for more details.

1.20 ssh_user

The operation × × user name used by MHA Manager and MHA Node to connect to the MySQL server. This parameter is used for a variety of purposes: for example, executing commands remotely (Manager- > MySQL), copying differential relay logs from latest slave to other slaves (MySQL- > MySQL), and so on.

The user must have at least read permissions on MySQL binary/relay log files and relay_log.info files. You must have write permission in the log directory (remote_workdir on each MySQL server).

The user must be able to connect to the server without interactivity. It is generally recommended to use SSH public key authentication. By default, ssh_user is the current operation × × user on the machine where manager resides.

1.21 remote_workdir

Each MHA Node (running on the MySQL server) generates the path to the log file. If the directory does not exist, MHA is created automatically. If sufficient permissions are not granted, MHA Node terminates. Neither MHA Manager nor MHA Node detects disk space, so you should be aware of this. By default, remote_workdir is "/ var/tmp".

1.22 master_binlog_dir

The directory on the master machine where MySQL generates binary logs. This parameter is valid when deadmaster can be connected through SSH, in order to read the binary log events necessary for replication. This parameter is required if there is no way to automatically detect the binary log directory after the MySQL hangs.

By default, master_binlog_dir is "/ var/lib/mysql,/var/log/mysql". / var/lib/mysql is the default binlog output directory for many MySQL versions, and / var/log/mysql is the default binlog output directory for MySQL packages on Ubuntu. Multiple directories can be set up, separated by commas (i.e / data1,/data2, …) .

1.23 log_level

The critical value of the log printed by MHA Manager. By default it is info, and you can also set debug/info/warning/error.

1.24 manager_workdir

MHA Manager generates a file directory for the relevant state. If it is not set, / var/tmp is used.

1.25 manager_log

MHA Manager produces a complete directory of logs. If it is not set, MHAManager is output to STDOUT/STDERR. When performing a manual switchover (interactive failover), MHAManager ignores manager_log and always outputs to STDOUT/STDERR.

1.26 check_repl_delay

By default, if a slave lags behind the relay logs of master over 100MB (equivalent to a relay logs that will apply more than 100MB), MHA will not select that slave as the new master because the recovery process takes too long. By setting check_repl_delay=0, MHA ignores replication latency when selecting new master. This option is useful if candidate_master=1 is set on a specified host and you want to make sure that the host becomes new master.

1.27 check_repl_filter

By default, if master and salves have different binary log/replication filtering rules, MHA prints errors and does not start monitoring or failover. This is to prevent unexpected errors, such as "Table not exists", during recovery. If you are 100% sure that setting different filtering rules will not cause recovery problems, you can set check_repl_filter = 0. MHA does not check the filtering rules when applying differential relaylogs, so there may be a "Table not exists" (or other) error if you set check_repl_filter = 0. You should be careful when setting this parameter.

1.28 latest_priority

By default, latest slave (the slave that receives the latest binlog events) is preferred as new master. If you want to control the priority (i.e. Host2- > host3- > host4), you can set latest_priority=0.

1.29 multi_tier_slave

Starting with MHA Manager version 0.52, multi-master replication configurations are supported. By default, setting 3 or more layers of replication hosts in the MHA configuration file is not allowed. For example, suppose host2 is copied from host1 and host3 is copied from host2. By default, it is not allowed to configure host1,host2,host3 in the configuration file, because this is a three-tier replication, MHA Manager will stop with an error. By setting multi_tier_slave, MHA Manager will not be terminated by three-tier replication, but the third-tier hosts will be ignored. If host1 (master) goes down, host2 will be chosen as the new master,host3 or continue to copy from host2.

1.30 ping_interval

This parameter indicates how often MHA Manager ping master (executes the sql statement). After losing the connection three times, MHA Manager decided to hang up the MySQL master. The default is 3 seconds. If the MHA Manager connection fails due to too many connections or verification errors, it will not be recorded in the number of ping failures.

1.31 ping_type

By default, MHA establishes a persistent connection to master and verifies the availability of master by executing "SELECT 1" (ping_type=SELECT). But in some cases, it is better to disconnect and reconnect each time, because it is stricter and faster to detect TCP connection layer failures. You can do this by setting up ping_type=CONNECT. Since 0. 56, ping_type=INSERT has been added.

1.32 secondary_check_script

Generally speaking, it is highly recommended to use two more network lines to test the availability of MySQL master servers. By default, MHA Manager is only detected with a single line: from Manager to Master. But this is not recommended. MHA can actually have two or more check lines by calling an additional script (specified by the secondary_check_script parameter). Example configuration:

Secondary_check_script = masterha_secondary_check-s remote_host1-s remote_host2

Masterha_secondary_check is already included in the MHA Manager package. The built-in masterha_secondary_check script is good in most cases, and you can call any other script here.

In the above example, MHA Manager detects the MySQL master server through Manager- (A)-> remote_host1- (B)-> master_host and Manager- (A)-> remote_host2- (B)-> master_host. If it appears on both lines: connection An is successful, but B is unsuccessful, then masterha_secondary_check exits (returns 0), and MHAManager decides that MySQL master is really dead, and then failover occurs. If An is unsuccessful, masterha_secondary_check exits (returns 2), and MHAManager guesses that there is a network problem and does not failover. If B is successful, masterha_secondary_check exits (returns 3), and MHAManager deduces that MySQL master is alive and does not failover.

Generally speaking, remote_host1 and remote_host2 should be on different network segments (from MHA Manager and MySQL servers).

MHA calls the script defined by the secondary_check_script parameter and automatically passes the parameters (so you don't need to set the following parameters in the configuration file). Masterha_secondary_check is appropriate in many cases, but if you need more functionality, you can write some network monitoring scripts yourself.

-- user= (SSH user name of the remote hosts. The value of the ssh_user parameter will be passed)

-- master_host= (hostname of master)

-- master_ip= (ip address of master)

-- master_port= (port number of master)

The built-in masterha_secondary_check script relies on the IO::Socket::INETPerl package and has been included by default since Perl v5.6.0. The masterha_secondary_check script also connects to the remote server through SSH, so SSH public key authentication is also required. Also, the masterha_secondary_check script attempts to establish a TCP connection from the remote server (set by-s) to the MySQLmaster. The max_connections parameter set in my.cnf does not affect, and if the TCP connection is successful, the aborted_connects value on the master is incremented by 1.

1.33 master_ip_failover_script

In a common HA environment, a virtual IP address is assigned on the master in many cases. If the master dies, the HA software (such as Pacemaker) will take over the virtual IP to the standby.

Another common way to handle this is to create a global catalog database that contains mappings between application names and read-write IP addresses (i.e. {app1_master1, 192.168.0.1}, {app_master2, 192.168.0.2},... ). In this case, the catalog database needs to be updated after the current master is hung up.

Both approaches have their own advantages and disadvantages. MHA does not enforce one of these methods, allowing users to use any of the IP address failover solutions, and the master_ip_failover_script parameter is used to resolve this. In other words, you need to write a script to make the application connect transparently to new master, which must be defined in the master_ip_failover_script parameter. Examples are as follows:

Master_ip_failover_script= / usr/local/sample/bin/master_ip_failover

Examples and capital preservation are located in (MHA Manager package) / samples/scripts/master_ip_failover. The sample script is included in the MHA Managertarball and GitHup branches.

MHA Manager calls master_ip_failover_script three times. The first time before entering master monitoring (script validity check), the second time before invoking the shutdown_script script, and the third time after applying the differential relay log to new master. MHA Manager passes in the following parameters (do not need to be configured in the configuration file).

Checking stage

-- command=status

-- ssh_user= (ssh username of the current master)

-- orig_master_host= (hostname of the current master)

-- orig_master_ip= (ip address of the current master)

-- orig_master_port= (port number of the current master)

Current master shutdown Pha

-- command=stop or stopssh

-- ssh_user= (ssh username of dead master, if accessible through SSH)

-- orig_master_host= (hostname of current (dead) master)

-- orig_master_ip= (ip address of current (dead) master)

-- orig_master_port= (port number of current (dead) master)

New master activation phase

-- command=start

-- ssh_user= (ssh username of new master)

-- orig_master_host= (hostname of dead master)

-- orig_master_ip= (ip address of dead master)

-- orig_master_port= (port number of dead master)

-- new_master_host= (hostname of new master)

-- new_master_ip= (ip address of new master)

-- new_master_port (port number of new master)

-- new_master_user= (user of new master)

-- new_master_password (password of new master)

If you use a shared virtual IP address on master, you may not need to do anything during the shutdown phase as long as you turn off the machine later in shutdown_script. During the newmaster activation phase, you can specify a virtual IP on the newmaster.

If you are using a catalog database, you need to record delete or update dead master during the master shutdown phase. During the new master activation phase, it can be recorded by insert/update new master. Also, you can do whatever you need to do so that the application can be written to new master. For example, SET GLOBAL read_only=0, create a database user with write privileges, and so on.

MHA Manager checks the code (return code) that the script exits. If the code returned by the script is 0 or 10pm MHA Manager continues. If the code returned by the script is not 0 or the 10PowerMHA Manager terminates, the failover will not continue. The parameter is empty by default.

1.34 master_ip_online_change_script

"similar to the master_ip_failover_script parameter, but not a command for master failover, but for the master online switchover command (masterha_master_switch--master_state=alive)." Pass in the following parameters.

Current master blocking write phase

-- command=stop or stopssh

-- orig_master_host= (hostname of current master)

-- orig_master_ip= (ip address of current master)

-- orig_master_port= (port number of current master)

-- orig_master_user= (user of current master)

-- orig_master_password= (password of current master)

-- orig_master_ssh_user= (supported from .56, ssh user of current master)

-- orig_master_is_new_slave= (supported from .56, indicating whether the original master will become the new slave)

Stage in which New master is granted write permission

-- command=start

-- orig_master_host= (hostname of orig master)

-- orig_master_ip= (ip address of orig master)

-- orig_master_port= (port number of orig master)

-- new_master_host= (hostname of new master)

-- new_master_ip= (ip address of new master)

-- new_master_port (port number of new master)

-- new_master_user= (user of new master)

-- new_master_password= (password of new master)

-- new_master_ssh_user= (supported from .56, ssh user of new master)

The current master blocks the write phase, and MHA executes FLUSH TABLES WITH READ LOCK on the current master. During the wirte period when new master is granted permission, you can do the same thing as master_ip_failover_script. For example, create authorized users, execute SET GLOBAL read_only=0, update catalog databases, and so on. If the code returned by the script is not 0 or 10, the MHA Manager terminates and the master switch does not continue.

The default parameter is empty.

The sample script is located in (MHA Manager package) / samples/scripts/master_ip_online_change.

1.35 shutdown_script

To prevent master from restarting the service, you need to forcibly shut down the master server. It's important to prevent brain fissure. Examples are as follows:

Shutdown_script= / usr/local/sample/bin/power_manager

The sample script is located in (MHA Manager package) / samples/scripts/power_manager. The sample script is included in the MHA Managertarball and GitHup branches.

Before calling shutdown_script, MHA Manager Huixian checks whether MySQL master can be accessed through SSH. If SSH is reachable (OS is available, but mysqld is not running, i.e. The data file is corrupted), and MHA Manager passes the following parameters.

-- command=stopssh

-- ssh_user= (ssh username used to connect to the master)

-- host= (hostname of master)

-- ip= (ip address of master)

-- port= (port number of master)

-- pid_file= (pid file of master)

If master is not reachable through SSH, MHA Manager passes in the following parameters.

-- command=stop

-- host= (hostname of master)

-- ip= (ip address of master)

The example script works as follows: if you pass in-- command=stopssh, the script connects to master through ssh and then kill all mysqld and mysqld_safe processes. If-pid_file is also passed, or if kill fails to drop all mysqld and mysqld_safe processes, the script will only kill the specified process. This parameter is useful when running multiple instances on master. If command=stopssh succeeds, the script returns code 10. If the return code is 10, MHA Manager will then connect to master and save the necessary binary logs. If you fail to connect to master through SSH, or if you pass in-- command=stop, the script attempts to shut down the machine. The shutdown command depends on Hhampw. For HP (iLO), ipmitool or SSL is usually used. For Dell (DRAC), dracadm is usually used. If the shutdown is successful, the script returns code 0. Otherwise, code 1 is returned. If the returned code is 0, the MHA Manager starts a failover. If the returned code is not 0 or 10, the MHA Manager terminates the failover. The parameter is empty by default.

Also, MHA Manager calls shutdown_script when it starts monitoring. The following parameters are passed in at this time. You can set it at this step. The control of power depends on Hmp W, so it is highly recommended to check power status at this step. If something goes wrong, you can realize it before you start monitoring.

-- command=status

-- host= (hostname of master)

-- ip= (ip address of master)

1.36 report_script

You may need to send a report (i.e. E-mail) when the failover completes or because the error ends. Report_script is used for this purpose. MHA Manager passes the following parameters.

-- orig_master_host= (hostname of dead master)

-- new_master_host= (hostname of new master)

-- new_slave_hosts= (hostnames of new slaves, separated by commas)

-- subject= (mail subject)

-- body= (body)

The parameter is empty by default.

The sample script is located in (MHA Manager package) / samples/scripts/send_report. The sample script is included in the MHA Managertarball and GitHub branches.

1.37 init_conf_load_script

You can use this script when you do not want to set plain text i.e. Password and repl_password in the configuration file. You can override the parameters of the global configuration file by returning the "name=value" pair from the script. Examples are as follows.

#! / usr/bin/perl

Print "password=$ROOT_PASS\ n"

Print "repl_password=$REPL_PASS\ n"

The parameter is empty by default.

The above contents are for their own translation, there are mistakes in the trouble, thank you.

# # #

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.