Explore MySQL's high-availability architecture MHA (7)

Explore MySQL's high-availability architecture MHA (7)

-----build MySQL High-availability series (total 9 articles)

The previous article introduced the KeepAlive read-write separation of this architecture!

This article mainly introduces the MHA installation part of this architecture!

About MHA

MHA (Master high Availability) is currently available in MySQL is a relatively mature solution, it was youshimaton by Nippon Dena Corporation (now on Facebook) . developed, is an excellent set of highly available software for failover and master-slave upgrading in MySQL high-availability environments. During the MySQL failover process, MHA can automatically complete the failover operation of the database within 0-30 seconds, and in the process of failover, MHA can ensure the consistency of the data to the maximum extent, in order to achieve a true sense of high availability.

The software consists of two parts: MHA Manager (Management node) and MHA node (data node). MHA Manager can be deployed individually on a separate machine to manage multiple master-slave clusters or on a single slave node. MHA node runs on each MySQL server, MHA Manager periodically probes the master node in the cluster, and when master fails, it automatically promotes the slave of the latest data to the new master and then all its His slave back to the new master. The entire failover process is completely transparent to the application.

During the MHA automatic failover process, MHA attempts to save the binary log from the main server of the outage, with maximum assurance that the data is not lost, but this is not always possible. For example, if the primary server hardware fails or cannot be accessed via SSH, MHA cannot save the binary logs and only fail over to lose the latest data. Using MySQL 5.5 's semi-synchronous replication can greatly reduce the risk of data loss. MHA can be combined with semi-synchronous replication. If only one slave has received the latest binary log, MHA can apply the latest binary logs to all other slave servers, thus guaranteeing data consistency across all nodes.

MHA Working principle

A. Save the binary log event from the master of the outage crash (Binlog events).

B. Identify the slave that contains the latest updates.

C. Apply the difference to the relay log (relay log) to the other slave.

D. Apply the binary log events saved from master (Binlog events).

E. Upgrade a Slave to the new master.

F. Make other slave connections to the new master for replication.

MHA Tool Kit

Manager tools

A.MASTERHA_CHECK_SSH: Check the SSH configuration of the MHA.

B.MASTERHA_CHECK_REPL: Check for MySQL replication.

C.masterha_manager: Start MHA.

D.masterha_check_status: Detects the current MHA running state.

E.masterha_master_monitor: Monitor Master for downtime.

F.masterha_master_switch: Control failover (automatic or manual).

G.masterha_conf_host: Adds or removes the configured server information.

Node tool

A.save_binary_logs: Save and copy the binary log of master.

B.apply_diff_relay_logs: A relay Log event that identifies differences and applies to other slave.

C.filter_mysqlbinlog: Removes unnecessary rollback events (MHA no longer uses this tool).

D.purge_relay_logs: Clears the trunk log (does not block SQL threads).

Let's start with the following steps:

Install node source package (depending on a lot of per package, please install in my installation order!)

rpm-ivhperl-dbi-1.620-1.el5.rfx.x86_64.rpm RPM-IVHMYSQL-SHARED-COMPAT-5.6.21-1.RHEL5.X86_64.RPMRPM-IVHPERL-DBD -mysql-3.0007-2.el5.x86_64.rpm #如果是6系统先安装 Rpm-ivhperl-data-showtable-3.3-1.2.el6.rf.noarch.rpmtar XFMHA4MYSQL-NODE-0.53.TAR.GZCD Mha4mysql-node-0.53perl makefile.plmake && make INSTALL#REDHAT5 series system, will appear Pleaseenter your CPAN site: [] random input anyway not CPAN module

          Install the manager source package (depending on a lot per package, please install it in my installation order!)

rpm -ivhperl-config-tiny-2.10-1.el5.noarch.rpm       rpm - ivhepel-release-5-4.noarch.rpmrpm -ivh perl-parallel-forkmanager-0.7.5-4.el5.noarch.rpmrpm - ivhperl-mail-sender-0.8.16-1.el5.rf.noarch.rpmrpm -ivhperl-mail-sendmail-0.79-1.2.el5.rf.noarch.rpmrpm  -ivhperl-params-validate-0.95-1.el5.rf.x86_64.rpmrpm - ihvperl-email-date-format-1.002-4.el5.noarch.rpmrpm -ivhperl-mime-lite-3.029-1.el5.rf.noarch.rpmrpm  -ivhperl-timedate-1.16-1.2.el5.rf.noarch.rpm      #解决依赖: Perl (Date::format)  perl ( Date::P arse) rpm -ivhperl-pod-escapes-1.04-5.el5.noarch.rpmrpm - Ivhperl-pod-simple-3.16-1.el5.rf.noarch.rpmrpm -ivhperl-test-pod-1.45-1.el5.rf.noarch.rpmrpm -ivh  perl-MailTools-2.12-1.el5.rf.noarch.rpm   #解决依赖: Perl (mail::send) rpm - ivhperl-log-dispatch-2.20-1.el5.noarch.rpmtar xfmha4mysql-manager-0.53.tar.gzcd  Mha4mysql-manager-0.53perl makefile. PLMAKE && MAKE INSTALL#REDHAT5 Series system,  pleaseenter your cpan site will appear:  []    do not use CPAN modules anyway

Configure SSH Trust (all machines do All)

Take 47 Machine Example (1) #生成公钥ssh-keygen-t RSA Generate Public key (2) #输出公钥匙cat id_rsa.pub ssh-rsa aaaab3nzac1yc2eaaaabiwaaaqea7 ... (3) operation of #在48, 50, 51, 52 respectively, vi Authorized_keys add 47 id_rsa.pub on the Machine (4) #测试ssh 10.142.132.52 datessh 10.142.132.51 datessh 10.142.132.50 datessh 10.142.132.48 datessh 10.142.132.47 Date Summary: The above 4 steps, the same operation on other machines, all the machines will be able to implement the SSH trust

To edit the Manager node configuration file//10.142.132.50

(1)  mkdir -p /etc/masterha    #创建目录 (2)  vi /etc/masterha/app1.cnf     #增加如下内容 [server default]user=root    #linux用于管理mysql用戶名password =mysql     #linux用于管理mysql密码ssh_user =root     #ssh免密钥登录的帐号名repl_user =lipengfei   #mysql复制帐号, used to synchronize the repl_password=lipengfei    #mysql复制帐号的密码manager_workdir between the master and slave machines, such as binary log =/app/masterha /app1     #manager目录        manager_log=/app/masterha/ app1/app1.log    #管理节点工作日志文件remote_workdir =/app/masterha/app1     #node   The working directory ping_interval=1     #ping间隔 used to generate the log to detect if Master is normal [server1]hostname=10.142.132.52    #具体IPcandidate_master =1     #优先级成为新mastercheck_repl_delay =0    # MHA the replication delay is ignored when the new master is selected. master_binlog_dir=/app/mysql/data   #binlog日志所在目录 [server2]hostname=10.142.132.51    #具体IPcandidate_master =1      #优先级成为新mastercheck_repl_delay =0        #MHA在选择新的Master时, the replication delay is ignored. master_binlog_dir=/app/mysql/data   #binlog日志所在目录 [server3]hostname=10.142.132.48   # Specific ipno_master=1      #不能成为主库 [server4]hostname=10.142.132.47    # Specific ipno_master=1   #不能成为主库

Start Mha-manager

Nohup masterha_manager--conf=/etc/masterha/app1.cnf--ignore_last_failover </dev/null >/app/masterha/app1/ App1.log2>&1 & #以nohup模式, set up in the background

Fault Testing

A. Manually stop 52 on the MySQL service, services MySQL STOPB. About 30 seconds, 51 automatically become the new main library #在47或48从库上show slave status can be seen c.52 start the MySQL service again, to manually add to the AB architecture #51是主库, use the following demo command to join AB architecture change Master to master_host= ' 10.142.132.51 ', master_port=3306,master_user= ' Lipengfei ', master _password= ' Lipengfei ', master_log_file= ' binlog.000001 ', master_log_pos=120;d. Manual stop 51 MySQL service e about 30 seconds, 52 automatically becomes the new main Library # Show slave status on 47 or 48 from the library.

Note the following 2 questions

A. When the primary DB fails, after switching to a different server, even if the original primary db is restored, it is not immediately possible to join the entire MHA system, and it has to be re-added manually to the AB architecture. B. When a switchover occurs, the management node's monitoring process automatically exits and needs to be started automatically with a script. Also need to delete app1.failover.complete this file, or the new master DB problem MHA will not switch.

Mha-manager Common Commands

(1) nohup masterha_manager--conf=/etc/masterha/app1.cnf--ignore_last_failover </dev/null >/app/masterha/app1 /app1.log2>&1 & #开启MHA Manager monitoring (2) MASTERHA_CHECK_STATUS--CONF=/ETC/MASTERHA/APP1.CNF #查看MHA Manager monitoring is normal (3) MASTERHA_STOP--CONF=/ETC/MASTERHA/APP1.CNF #关闭MHA Manage Monitoring (4) masterha_check_ssh--conf=/etc/ MASTERHA/APP1.CNF #检查SSH配置 (5) masterha_check_repl--conf=/etc/masterha/app1.cnf #检查整个复制环境状况

So far, our mah function has been configured to end!

As long as the friends carefully click on the article I wrote step-by-step operation, I believe you can also succeed, come on!

This article is from "Can't finish the road, can't read the book!" blog, be sure to keep this source http://51power.blog.51cto.com/3549599/1672730

Explore MySQL's high-availability architecture MHA (7)