mysql mha高可用性安装配置

zsyzhou

Installation
　　bmildren edited this page on 27 Jan 2016       ·                 1 revision
Pages 30

• 　　Home
  
• 　　Advantages
  
• 　　Architecture
  
• 　　CommercialSupport
  
• 　　Configuration
  
• 　　Downloads
  
• 　　FAQ
  
• 　　GTID_Based_Failover
  
• 　　HowMHAWorks
  
• 　　Installation
  
• 　　masterha_check_repl
  
• 　　masterha_check_status
  
• 　　masterha_conf_host
  
• 　　masterha_manager
  
• 　　masterha_master_switch
  
• 　　Show 15 more pages…
  

Clone this wiki locally

• 　　Installation
  
  
  
  • 　　Downloading MHA Node and MHA Manager
    
  • 　　Installing MHA Node
    
  • 　　Installing MHA Manager
    
  
  

Installation
　　MHA consists of MHA Manager and MHA Node packages. MHA Manager runs
on a manager server, and MHA Node runs on each MySQL server. MHA Node
programs do not run always, but are invoked from MHA manager programs
when needed (at configuration check, failover, etc).  Both MHA Manager
and MHA Node are written in Perl.
Downloading MHA Node and MHA Manager
　　MHA Node and MHA Manager can be downloaded from "Downloads" section. These are stable packages.
　　If you want to try development source trees, check out GitHub source trees. MHA Manager is hosted here, and MHA Node is hosted here.
Installing MHA Node
　　MHA Node has scripts and dependent perl modules that do the following.

• 　　save_binary_logs: Saving and copying dead master's binary logs
  
• 
  　　apply_diff_relay_logs:>
  
• 
  　　purge_relay_logs: Purging>
  

　　You need to install MHA Node to all MySQL servers (both master and
slave). You also need to install MHA Node on a management server becauseMHA Manager modules internally depend on MHA Node modules.  MHA Managerinternally connects to managed MySQL servers via SSH and executes MHA
Node scripts.  MHA Node does not depend on any external Perl modules
except DBD::mysql so you should be able to install easily.
　　On RHEL/CentOS distribution, you can install MHA Node rpm package as below.
## If you have not installed DBD::mysql, install it like below, or install from source.　　
# yum install perl-DBD-MySQL
　　

　　
## Get MHA Node rpm package from "Downloads" section.
　　
# rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
　　On Ubuntu/Debian distribution, you can install MHA Node deb package as below.
## If you have not installed DBD::mysql, install it like below, or install from source.　　
# apt-get install libdbd-mysql-perl
　　

　　
## Get MHA Node deb package from "Downloads" section.
　　
# dpkg -i mha4mysql-node_X.Y_all.deb
　　You can also install MHA Node from source.
## Install DBD::mysql if not installed　　
$ tar -zxf mha4mysql-node-X.Y.tar.gz
　　
$ perl Makefile.PL
　　
$ make
　　
$ sudo make install
Installing MHA Manager
　　MHA Manager has administrative command line programs such as
masterha_manager, masterha_master_switch, etc, and dependent Perl
modules.  MHA Manager depends on the following Perl modules. You need toinstall them before installing MHA Manager. Do not forget to install
MHA Node.

• 　　MHA Node package
  
• 　　DBD::mysql
  
• 　　Config::Tiny
  
• 　　Log::Dispatch
  
• 　　Parallel::ForkManager
  
• 　　Time::HiRes (included from Perl v5.7.3)
  

　　On RHEL/CentOS distribution, you can install MHA Manager rpm package as below.
## Install dependent Perl modules　　
# yum install perl-DBD-MySQL
　　
# yum install perl-Config-Tiny
　　
# yum install perl-Log-Dispatch
　　
# yum install perl-Parallel-ForkManager
　　

　　
## Install MHA Node, since MHA Manager uses some modules provided by MHA Node.
　　
# rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
　　

　　
## Finally you can install MHA Manager
　　
# rpm -ivh mha4mysql-manager-X.Y-0.noarch.rpm
　　On Ubuntu/Debian distribution, you can install MHA Manager deb package as below.
## Install dependent Perl modules　　
# apt-get install libdbd-mysql-perl
　　
# apt-get install libconfig-tiny-perl
　　
# apt-get install liblog-dispatch-perl
　　
# apt-get install libparallel-forkmanager-perl
　　

　　
## Install MHA Node, since MHA Manager uses some modules provided by MHA Node.
　　
# dpkg -i mha4mysql-node_X.Y_all.deb
　　

　　
## Finally you can install MHA Manager
　　
# dpkg -i mha4mysql-manager_X.Y_all.deb
　　You can also install MHA Manager from source.
## Install dependent Perl modules　　
# MHA Node (See above)
　　
# Config::Tiny
　　
## perl -MCPAN -e "install Config::Tiny"
　　
# Log::Dispatch
　　
## perl -MCPAN -e "install Log::Dispatch"
　　
# Parallel::ForkManager
　　
## perl -MCPAN -e "install Parallel::ForkManager"
　　
## Installing MHA Manager
　　
$ tar -zxf mha4mysql-manager-X.Y.tar.gz
　　
$ perl Makefile.PL
　　
$ make
　　
$ sudo make install
Configuration
　　bmildren edited this page on 27 Jan 2016       ·                 1 revision
Pages 30

• 　　Home
  
• 　　Advantages
  
• 　　Architecture
  
• 　　CommercialSupport
  
• 　　Configuration
  
• 　　Downloads
  
• 　　FAQ
  
• 　　GTID_Based_Failover
  
• 　　HowMHAWorks
  
• 　　Installation
  
• 　　masterha_check_repl
  
• 　　masterha_check_status
  
• 　　masterha_conf_host
  
• 　　masterha_manager
  
• 　　masterha_master_switch
  
• 　　Show 15 more pages…
  

Clone this wiki locally

• 　　Writing an application configuration file
  
• 　　Writing a global configuration file
  
• 　　Binlog server
  

Writing an application configuration file
　　To make MHA work, you have to create a configuration file and set
parameters. Parameters include hostname of each MySQL server, MySQL
username and password, working directory name, etc. The whole parametersare described at Parameters page.
　　The below is an example configuration file.
　　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
　　All parameters must follow "param=value" syntax. For example, the below parameter setting is incorrect.
[server1]　　
hostname=host1
　　
# incorrect: must be "no_master=1"
　　
no_master
　　Application-scope parameters should be written in [server default] block.  In [serverN]blocks, you should set local-scope parameters. hostname is mandatory
local-scope parameter so has to be written here. Block name should startfrom "server". Internally server configurations are sorted by block
name, and sorted order matters when MHA decides new master (See FAQ for details).
Writing a global configuration file
　　If you plan to manage two or more MySQL applications ((master,
slaves) pairs) from a single manager server, creating a global
configuration file makes it much easier to configure.
Once you write parameters in the global configuration file, you do not
need to set parameters for each application. If you create a file at
/etc/masterha_default.cnf, MHA Manager scripts automatically reads the
file as a global configuration file.
　　You can set application scope parameters in the global configuration
file. For example, if MySQL administrative user and password are
identical on all MySQL servers, you can set "user" and "password" here.
Global Configuration Example:

　　Global configuration file (/etc/masterha_default.cnf)

[server default]　　
user=root
　　
password=rootpass
　　
ssh_user=root
　　
master_binlog_dir= /var/lib/mysql
　　
remote_workdir=/data/log/masterha
　　
secondary_check_script= masterha_secondary_check -s remote_host1 -s remote_host2
　　
ping_interval=3
　　
master_ip_failover_script=/script/masterha/master_ip_failover
　　
shutdown_script= /script/masterha/power_manager
　　
report_script= /script/masterha/send_master_failover_mail
　　These parameters are applied to all applications monitored by MHA Manager running on the host.
　　Application configuration file should be written separately. The
below example is configuraing app1 (host1-4) and app2 (host11-14).

　　app1:

　　manager_host$ cat /etc/app1.cnf
[server default]　　
manager_workdir=/var/log/masterha/app1
　　
manager_log=/var/log/masterha/app1/app1.log
　　

　　
[server1]
　　
hostname=host1
　　
candidate_master=1
　　

　　
[server2]
　　
hostname=host2
　　
candidate_master=1
　　

　　
[server3]
　　
hostname=host3
　　

　　
[server4]
　　
hostname=host4
　　
no_master=1
　　In the above case, MHA Manager generates working files (including
status files) under /var/log/masterha/app1, and generates log file at
/var/log/masterha/app1/app1.log. You need to set unique directory/file
names when monitoring other applications.

　　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
　　If you set same parameters on both global configuration file and
application configuration file, the latter (application configuration)
is used.
Binlog server
　　Starting from MHA version 0.56, MHA supports new section [binlogN]. In binlog section, you can define mysqlbinlog streaming servers.When MHA does GTID based failover, MHA checks binlog servers, and if
binlog servers are ahead of other slaves, MHA applies differential
binlog events to the new master before recovery. When MHA does non-GTID
based (traditional) failover, MHA ignores binlog servers.
　　Below is an example configuration.
　　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
　　转自： https://github.com/yoshinorim/mha4mysql-manager/wiki