Similar to most Linux applications, the correct use of MHA depends on a reasonable configuration file. The configuration file of MHA is similar to that of mysql's my. cnf file.
Similar to most Linux applications, the correct use of MHA depends on a reasonable configuration file. The configuration file of MHA is similar to that of mysql's my. cnf file.
Similar to most Linux applications, the correct use of MHA depends on a reasonable configuration file. MHA configuration file and mysql my. the cnf file configuration is similar. The configuration file is configured by module and param = value. The configuration file is located on the Management node and usually includes the host name, mysql user name, and password of each mysql server, working directory and so on. This article lists a single MHA and some examples of using global configuration to manage multiple MHA configuration files for your reference.
1. Single MHA configuration sample
Manager_host $ cat/etc/app1.cnf
[Server default]
# Log on to the mysql database account and password. The default value is root because you need to stop slave, change master, and reset slave.
User = root
Password = mysqlpass
# Working directory on the manager # located in the management node working directory
Manager_workdir =/var/log/masterha/app1
# Manager log file # job log file on the Management Node
Manager_log =/var/log/masterha/app1/app1.log
# Working directory on MySQL servers
# The working directory on the node used to generate logs. If the directory does not exist, MHA node is automatically created, and the corresponding permissions are required. Otherwise, the node is terminated.
# The default directory is "/var/tmp ".
Remote_workdir =/var/log/masterha/app1
# In the [serverN] section, the configuration information is configured for each node and the scope is individual nodes. The writing order of each node affects the order of new master nodes.
# You can also configure the candidate_master parameter to determine which node has the priority to become the new master.
[Server1]
Hostname = host1
[Server2]
Hostname = host2
[Server3]
Hostname = host3
2. Multiple MHA configuration Samples
If multiple MHA sets are deployed based on a single management node in the production environment, you can use the global configuration file to configure the same or common parts for simplified configuration and ease of management.
Assuming that the/etc/masterha_default.cnf file is created, the MHA Manager script first reads the file and then reads the specified configuration file.
This function is similar to/etc/profile and then reads ~ /. Bash_profile
If the global configuration file is not configured, you will receive the following prompt:
[Warning] Global configuration file/etc/masterha_default.cnf not found. Skipping.
A. Global configuration file Samples
For example:/etc/masterha_default.cnf
[Server default]
User = root
Password = rootpass
Ssh_user = root
# Position of the binlog on the master node of the mysql database. This parameter is used to read the binlog event in sequence through ssh when the master node dies.
# This parameter needs to be configured because the binlog location cannot be automatically obtained through the replication mechanism after the master node dies
# The default binlog location for rpm installation is as follows. adjustments should be made as appropriate.
Master_binlog_dir =/var/lib/mysql
Remote_workdir =/data/log/masterha
# Used to check the connectivity between nodes. For details, refer to the description section of MHA parameters.
Secondary_check_script = masterha_secondary_check-s remote_host1-s remote_host2
Ping_interval = 3
# Define the scripts used to implement VIP drift, followed by shutdown and report scripts
Master_ip_failover_script =/script/masterha/master_ip_failover
Shutdown_script =/script/masterha/power_manager
Report_script =/script/masterha/send_master_failover_mail
B. Separate MHA configuration Samples
The following are two MHA configuration files for different applications:
App1:
Manager_host $ cat/etc/app1.cnf
[Server default]
Manager_workdir =/var/log/masterha/app1 # working directory Author: Leshami
Manager_log =/var/log/masterha/app1/app1.log # log File Blog:
[Server1]
Hostname = host1
Candidate_master = 1
[Server2]
Hostname = host2
Candidate_master = 1
[Server3]
Hostname = host3
[Server4]
Hostname = host4
No_master = 1
App2:
Manager_host $ cat/etc/app2.cnf
[Server default]
Manager_workdir =/var/log/masterha/app2
Manager_log =/var/log/masterha/app2/app2.log
[Server1]
Hostname = host11
Candidate_master = 1
[Server2]
Hostname = host12
Candidate_master = 1
[Server3]
Hostname = host13
[Server4]
Hostname = host14
No_master = 1
NOTE: For the above configuration, if the configuration of each application is different from the global configuration, the application configuration has the highest priority, that is, the same item, the value of the application configuration will replace the global configuration value.
3. Binlog server
This function is supported by MHA 0.56. You can define the [binlogN] Option. In this section, you can define mysqlbinlog streaming servers.
If GTID is enabled, MHA checks the binlog server, and the binlog server logs are applied to the binlog server before other slave node logs are recovered.
If GTID is not enabled, MHA ignores binlog servers. Sample:
Manager_host $ cat/etc/app1.cnf
[Server default]
# Mysql user and password
User = root
Password = mysqlpass
# Working directory on the manager
Manager_workdir =/var/log/masterha/app1
# Manager log file
Manager_log =/var/log/masterha/app1/app1.log
# Working directory on MySQL servers
Remote_workdir =/var/log/masterha/app1
[Server1]
Hostname = host1
[Server2]
Hostname = host2
[Server3]
Hostname = host3
[Binlog1]
Hostname = binlog_host1
[Binlog2]
Hostname = binlog_host2
Reference: Writing an application configuration file
This article permanently updates the link address: