MYSQL + MHA +keepalive + VIP installation Configuration (ii)--MHA configuration

Source: Internet
Author: User
Tags create directory failover install perl


I. GENERAL overview


1, MHA Introduction


MHA (Master high Availability) is a software package that automates master failover and slave promotion. It is a standard-based MySQL replication (asynchronous/semi-synchronous).

MHA has two components: MHA Manager (Management node) and MHA node (data node).

MHA Manager can be deployed individually on a standalone machine to manage multiple master-slave clusters or on a single slave. MHA Manager detects node nodes in the cluster, and when it discovers that Master has failed, it can automatically promote the slave with the latest data to the new master and then all its Its slave is directed to the new master. The entire failover process is transparent to the application.

MHA node runs on each MySQL server (master/slave/manager), which accelerates failover by monitoring scripts with parsing and scavenging logs capabilities.


2. MHA Working principle


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

-Identify slave that contain the latest updates.

-Apply the difference of the trunk log (relay log) to the other slave.

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

-Upgrade a Slave to the new master.

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


3. MHA Toolkit:


(1), Manager tools:

-Masterha_check_ssh: Check the SSH configuration of the MHA.

-Masterha_check_repl: Check MySQL replication.

-Masterha_manager: Start MHA.

-Masterha_check_status: Detects the current MHA running state.

-Masterha_master_monitor: Monitor Master for downtime.

-Masterha_master_switch: Control failover (automatic or manual).

-Masterha_conf_host: Adds or removes the configured server information.


(2), node tool (these tools are usually triggered by MHA manager's script, without manual operation).

-Save_binary_logs: Save and copy the binary log of master.

-Apply_diff_relay_logs: Identifies the difference of the relay log event and applies it to other slave.

-Filter_mysqlbinlog: Remove unnecessary rollback events (MHA is no longer using this tool).

-Purge_relay_logs: Clears the trunk log (does not block SQL threads).


Second, the host deployment


Manager Machine: 192.168.1.201 Manager Installation: mha4mysql-manager-0.54-0.el6.noarch.rpm

Master machine: 192.168.1.231 Node Installation: mha4mysql-node-0.54-0.el6.noarch.rpm

Slave1 machine: 192.168.1.232 (alternate Master) node installation: mha4mysql-node-0.54-0.el6.noarch.rpm

Third, first use Ssh-keygen to achieve mutual key-free login between three hosts


[manager--201]

1. Generate Certificate

shell> ssh-keygen-t rsa-b 2048//Always press ENTER to generate directly.

Shell> SCP id_rsa.pub [email protected]:/root/.ssh///replicate to host 231

Shell> SCP id_rsa.pub [email protected]:/root/.ssh///replicate to host 232

2. Execute under/root/.ssh/in host 231, 232

Cat Id_rsa.pub >> Authorized_keys

Import the public key into the/root/.ssh/authorized_keys file

3. Test 201 no secret login to 231, 232

SSH 192.168.1.231

SSH 192.168.1.232

[node--231, 232]

Repeat the above steps.

Through SSH test any two hosts between 22 can be no secret login.

Note: If you cannot implement any of the two hosts between 22 can be no secret login, the following steps will be problematic.


Iv. Installing the Mhamha4mysql-node,mha4mysql-manager package


1. Manager Mha4mysql-manager Software Installation



[manager--201]

shell> Yum Install Perl

shell> Yum Install Cpan

Shell> RPM-IVH mha4mysql-manager-0.53-0.el6.noarch.rpm

Error

Perl (Config::tiny) is needed by Mha4mysql-manager-0.53-0.noarch

Perl (Log::D ispatch) is needed by Mha4mysql-manager-0.53-0.noarch

Perl (Log::D ispatch::file) is needed by Mha4mysql-manager-0.53-0.noarch

Perl (Log::D ispatch::screen) is needed by Mha4mysql-manager-0.53-0.noarch

Perl (Parallel::forkmanager) is needed by Mha4mysql-manager-0.53-0.noarch

Perl (Time::hires) is needed by Mha4mysql-manager-0.53-0.noarch


Description There are many dependent packages that are not installed, workaround:



Shell> wget ftp://ftp.muug.mb.ca/mirror/cent ... 8-41.el5.x86_64.rpm

Shell> wget ftp://ftp.muug.mb.ca/mirror/cent ... 9-15.el6.x86_64.rpm

Shell> wget http://downloads.naulinux.ru/pub ... 27-1.el6.noarch.rpm

Shell> wget http://dl.fedoraproject.org/pub/.... 9-1.el6.noarch.rpm

Shell> wget http://dl.fedoraproject.org/pub/... 16-3.el6.noarch.rpm

Shell> wget http://dl.fedoraproject.org/pub/... 9-12.el6.noarch.rpm

Shell> wget http://mirror.centos.org/centos/... -136.el6.x86_64.rpm

shell> RPM-IVH perl-parallel-forkmanager-0.7.9-1.el6.noarch.rpm perl-log-dispatch-2.27-1.el6.noarch.rpm perl-mail-sender-0.8.16-3.el6.noarch.rpm perl-mail-sendmail-0.79-12.el6.noarch.rpm perl-time-hires-1.9721-136.el6.x86_64.rpm



Re-install


Shell> RPM-IVH mha4mysql-manager-0.53-0.el6.noarch.rpm

2. Node Mhamha4mysql-node Software Installation



Shell>wget http://mirror.centos.org/centos/... 13-3.el6.x86_64.rpm

SHELL>RPM-IVH perl-dbd-mysql-4.013-3.el6.x86_64.rpm

Shell>wget http://mysql-master-ha.googlecod ... 54-0.el6.noarch.rpm

SHELL>RPM-IVH mha4mysql-node-0.54-0.el6.noarch.rpm

The installation process may be error (specific errors I did not write down) are dependent on the package, so solve it

Shell>yum Install Perl-mime-lite

Yum Install Perl-params-validate


V. Configuration of MHA


1. Configure the MHA file on the management manager



shell> mkdir-p/MASTERHA/APP1//Create Directory

Shell> MKDIR/ETC/MASTERHA//Create Directory

Shell> VI/ETC/MASTERHA/APP1.CNF//Creating a configuration file

[Server default]

User=root//linux for managing MySQL user names

Password=sunney//linux for managing MySQL passwords

Manager_workdir=/masterha/app1

Manager_log=/masterha/app1/manager.log

Remote_workdir=/masterha/app1

Ssh_user=root//ssh password-free key login account name

Repl_user=sunney//mysql copy account, used to synchronize binary logs between Master and slave machines, etc.

Repl_password=sunney//mysql Password

Ping_interval=1//ping interval to detect if Master is normal

[Server1]

hostname=192.168.1.231

#ssh_port =9999

Master_binlog_dir=/var/lib/mysql//mysql Database directory different installation mode directory is not the same

Candidate_master=1//master Machine is down, it is preferred to enable this as a new master

[Server2]

hostname=192.168.1.232

#ssh_port =9999

Master_binlog_dir=/var/lib/mysql

Candidate_master=1


2. Masterha_check_ssh tool verifies that SSH trust login is successful


[manager:201]

Shell> Masterha_check_ssh--conf=/etc/masterha/app1.cnf

Note: Using Ssh-keygen to achieve mutual key-free login between three hosts determines whether this step is successful.


Wed APR 22:10:01-[debug] OK.

Wed APR 22:10:01-[INFO] All SSH connection tests passed successfully.

Success!


3. MASTERHA_CHECK_REPL tool verifies that MySQL replication is successful


[manager:201]

Shell> Masterha_check_repl--conf=/etc/masterha/app1.cnf

Note: The master--slaver in the previous article succeeded in determining whether this step was successful. Or the user account for the MHA file configuration.



Wed APR 22:10:56-[INFO] Checking replication Health on 192.168.1.232.

Wed APR 22:10:56-[info] OK.

Wed APR 22:10:56-[WARNING] master_ip_failover_script is not defined.

Wed APR 22:10:56-[WARNING] shutdown_script is not defined.

Wed APR 22:10:56-[INFO] Got exit code 0 (not master dead).


MySQL Replication Health is OK.


Success.


4. Start MHA Manager and monitor the log files


[manager:201]

shell> nohup masterha_manager--conf=/etc/masterha/app1.cnf >/tmp/mha_manager.log 2>&1

shell> tail-f/masterha/app1/manager.log//This is best done in a new window

Results:



Thu APR 04:41:03-[INFO] slaves settings check done.

Thu APR 04:41:03-[INFO]

192.168.1.231 (Current master)

+--192.168.1.232

Thu APR 04:41:03-[WARNING] master_ip_failover_script is not defined.

Thu APR 04:41:03-[WARNING] shutdown_script is not defined.

Thu APR 04:41:03-[info] Set Master ping interval 1 seconds.

Thu APR 04:41:03-[WARNING] secondary_check_script is not defined. It is highly recommended setting it to check the master reachability from the or more routes.

Thu APR 04:41:03-[info] Starting ping Health check on 192.168.1.231 (192.168.1.231:3306):

Thu APR 04:41:03-[info] Ping (SELECT) succeeded, waiting until MySQL doesn ' t respond.


5, Test Master (231) After the outage, will automatically switch


[master--231]

Shell>service MySQL Stop


[manager--201]

Shell>tail-f tail-f/masterha/app1/manager.log

The-----log appears as follows------

--------Failover Report-----


App1:mysql Master failover 192.168.1.231 to 192.168.1.232 succeeded


Master 192.168.1.231 is down!


Check MHA Manager logs at Localhost.localdomain:/masterha/app1/manager.log for details.


Started Automated (non-interactive) failover.

The latest slave 192.168.1.232 (192.168.1.232:3306) has a relay logs for recovery.

Selected 192.168.1.232 as a new master.

192.168.1.232:ok:applying all logs succeeded.

Generating relay diff files from the latest slave succeeded.

192.168.1.232:resetting Slave info succeeded.

Master failover to 192.168.1.232 (192.168.1.232:3306) completed successfully.




6. After the failover, restore the original master with the command


(1), executed on the old master



1. Perform on the old master

Shell>service MySQL start//Database Startup

Shell>mysql-usunney-psunney

mysql> Reset Master;

mysql> Change Master to master_host= ' 192.168.1.232 ', master_port=3306, master_user= ' Sunney ', master_password= ' Sunney ', master_log_file= ' mysql-bin.000031 ', master_log_pos=112;

mysql> start slave; #暂时先把旧master变为slave


(2) Then on the manager node:




shell> Masterha_master_switch--master_state=alive--conf=/etc/masterha/app1.cnf


Always enter Yes in the process;


In this case, the MySQL master and slave switch. You can test the data in the new Master (232) table to add data, in the new Slave (231) corresponding to the table in the data synchronization has been implemented.


Vi. The MHA has been configured and tested. But if the program is connected to the database and does not automatically switch IP, then how do we do it, please look forward to a KeepAlive + VIP installation configuration.


This article is from the "lake and Laughter" blog, please make sure to keep this source http://hashlinux.blog.51cto.com/9647696/1793486

MYSQL + MHA +keepalive + VIP installation Configuration (ii)--MHA configuration

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.