MySQL高可用之MHA的实现及大规模运维实践

合集下载

MySQL高可用篇之MHA集群

MySQL⾼可⽤篇之MHA集群很多⼩伙伴反映说⽹上的MHA教程甚⾄收费的课程⾥的MHA教程都存在坑，不少教程只是搭建完成了，是否真的能在主库宕机时⾃动切换不得⽽知，鉴于此情况，简单写了⼀个MHA集群的搭建步骤。

由于搭建的次数（本⽂篇幅相对较长，建议收藏，如对你有帮助，帮忙⽂末点个推荐或关注公众号：数据库⼲货铺，谢谢）1 准备⼯作1.1 修改主机名vim /etc/hosts# 添加对应主机192.168.28.128 mha1192.168.28.131 mha2192.168.28.132 mha31.2 关闭防⽕墙及修改selinux# 关闭防⽕墙systemctl stop firewalldsystemctl disable firewalld # 关闭⾃启动# 修改selinuxvim /etc/sysconfig/selinuxSELINUX=disabled # 设置为disabled1.3 部署⼀套1主2从的MySQL集群创建主从可以参考 MySQL主从搭建注意必须有如下参数server-id=1 # 每个节点不能相同log-bin=/data/mysql3306/logs/mysql-binrelay-log=/data/mysql3306/logs/relay-logskip-name-resolve # 建议加上⾮必须项#read_only = ON # 从库开启，主库关闭只读relay_log_purge = 0 # 关闭⾃动清理中继⽇志log_slave_updates = 1 # 从库通过binlog更新的数据写进从库⼆进制⽇志中，必加，否则切换后可能丢失数据创建mha管理账号# 特别注意： mha的密码不要出现特殊字符，否则后⾯⽆法切换主库create user mha@'192.168.28.%' identified by 'MHAadmin123';create user mha@'localhost' identified by 'MHAadmin123';grant all on *.* to mha@'192.168.28.%';grant all on *.* to mha@'localh 1.4 配置互信MHA管理节点上执⾏（但建议每台主机均执⾏，便于切换管理节点及集群间维护，但注意主机安全），包含本机到本机的互信ssh-keygenssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.28.128ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.28.131ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.28.132配置完成后记得测试⼀下是否配置成功（必须测试）ssh root@192.168.28.128ssh root@192.168.28.131ssh root@192.168.28.132ssh root@mha1ssh root@mha2ssh root@mha32 MHA⼯具部署2.1 安装MHA相关依赖包yum install perl-DBI perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes perl-Params-Validate perl-DateTime -yyum install perl-ExtUtils-Embed -yyum install cpan -yyum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker -y注意： MySQL数据库安装时不建议⽤rpm包⽅式安装，否则此处部分包可能有冲突2.2 安装MHA 管理及node节点# 所有节点均需安装rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm#管理节点需安装（其他节点也可以安装）mha4mysql-manager-0.58-0.el7.centos.noarch.rpm如果以上安装包未安装全，则会出现类似下⾯的错误，如出现可以调整yum源或找下载好的同学获取[root@mha3 local]# rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpmerror: Failed dependencies:perl(Log::Dispatch) is needed by mha4mysql-manager-0.58-0.el7.centos.noarchperl(Log::Dispatch::File) is needed by mha4mysql-manager-0.58-0.el7.centos.noarchperl(Log::Dispatch::Screen) is needed by mha4mysql-manager-0.58-0.el7.centos.noarchperl(Parallel::ForkManager) is needed by mha4mysql-manager-0.58-0.el7.centos.noarch2.3 配置mha创建配置⽂件路径、⽇志⽂件路径mkdir -p /etc/masterhamkdir -p /var/log/masterha/app1创建mha配置⽂件vim /etc/masterha/app1.confuser=mha[server default]manager_workdir=/var/log/masterha/app1manager_log=/var/log/masterha/app1/app1.logmaster_ip_failover_script=/usr/bin/master_ip_failovermaster_ip_online_change_script=/usr/bin/master_ip_online_change##mysql⽤户名和密码user=mhapassword=MHAadmin123password=MHAadmin123ssh_user=rootrepl_user=replrepl_password=replping_interval=3remote_workdir=/tmpreport_script=/usr/bin/send_report# secondary_check_script 可以不加# secondary_check_script=/usr/bin/masterha_secondary_check -s mha2 -s mha3 --user=mha --master_host=mha1 --master_ip=192.168.28.128 --master_port=3306 --password=MHAadmin123shutdown_script=""report_script=""[server1]hostname=192.168.28.128master_binlog_dir=/data/mysql3306/logscandidate_master=1[server2]hostname=192.168.28.131master_binlog_dir=/data/mysql3306/logscandidate_master=1check_repl_delay=0[server3]hostname=192.168.28.132master_binlog_dir=/data/mysql3306/logsno_master=1配置两个重要的脚本 master_ip_failover 、 master_ip_online_change/usr/bin/master_ip_failovervim /usr/bin/master_ip_failover#!/usr/bin/env perluse strict;use warnings FATAL => 'all';use Getopt::Long;my ($command, $ssh_user, $orig_master_host, $orig_master_ip,$orig_master_port, $new_master_host, $new_master_ip, $new_master_port);my $vip = '192.168.28.199/24';my $if = 'ens33';my $ssh_start_vip = "/sbin/ip addr add $vip dev $if";my $ssh_stop_vip = "/sbin/ip addr del $vip dev $if";GetOptions('command=s' => \$command,'ssh_user=s' => \$ssh_user,'orig_master_host=s' => \$orig_master_host,'orig_master_ip=s' => \$orig_master_ip,'orig_master_port=i' => \$orig_master_port,'new_master_host=s' => \$new_master_host,'new_master_ip=s' => \$new_master_ip,'new_master_port=i' => \$new_master_port,);exit &main();sub main {print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";if ( $command eq "stop" || $command eq "stopssh" ) {my $exit_code = 1;eval {print "Disabling the VIP on old master: $orig_master_host \n";&stop_vip();$exit_code = 0;};if ($@) {warn "Got Error: $@\n";exit $exit_code;}exit $exit_code;}elsif ( $command eq "start" ) {my $exit_code = 10;eval {print "Enabling the VIP - $vip on the new master - $new_master_host \n";&start_vip();$exit_code = 0;};if ($@) {warn $@;exit $exit_code;}exit $exit_code;}elsif ( $command eq "status" ) {print "Checking the Status of the script.. OK \n";exit 0;}else {&usage();exit 1;}}sub start_vip() {`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;}sub stop_vip() {return 0 unless ($ssh_user);`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;}sub usage {print "Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n"; }/usr/bin/master_ip_online_changevim /usr/bin/master_ip_online_change#!/usr/bin/env perluse strict;use warnings FATAL => 'all';use Getopt::Long;#my (# $command, $ssh_user, $orig_master_host, $orig_master_ip,# $orig_master_port, $new_master_host, $new_master_ip, $new_master_port#);my ($command, $orig_master_is_new_slave, $orig_master_host,$orig_master_ip, $orig_master_port, $orig_master_user,$orig_master_password, $orig_master_ssh_user, $new_master_host,$new_master_ip, $new_master_port, $new_master_user,$new_master_password, $new_master_ssh_user,);my $vip = '192.168.28.199/24';my $if = 'ens33';my $ssh_start_vip = "/sbin/ip addr add $vip dev $if";my $ssh_stop_vip = "/sbin/ip addr del $vip dev $if";my $ssh_stop_vip = "/sbin/ip addr del $vip dev $if";my $ssh_user = "root";GetOptions('command=s' => \$command,#'ssh_user=s' => \$ssh_user,#'orig_master_host=s' => \$orig_master_host,#'orig_master_ip=s' => \$orig_master_ip,#'orig_master_port=i' => \$orig_master_port,#'new_master_host=s' => \$new_master_host,#'new_master_ip=s' => \$new_master_ip,#'new_master_port=i' => \$new_master_port,'orig_master_is_new_slave' => \$orig_master_is_new_slave,'orig_master_host=s' => \$orig_master_host,'orig_master_ip=s' => \$orig_master_ip,'orig_master_port=i' => \$orig_master_port,'orig_master_user=s' => \$orig_master_user,'orig_master_password=s' => \$orig_master_password,'orig_master_ssh_user=s' => \$orig_master_ssh_user,'new_master_host=s' => \$new_master_host,'new_master_ip=s' => \$new_master_ip,'new_master_port=i' => \$new_master_port,'new_master_user=s' => \$new_master_user,'new_master_password=s' => \$new_master_password,'new_master_ssh_user=s' => \$new_master_ssh_user,);exit &main();sub main {print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";if ( $command eq "stop" || $command eq "stopssh" ) {my $exit_code = 1;eval {print "Disabling the VIP on old master: $orig_master_host \n";&stop_vip();$exit_code = 0;};if ($@) {warn "Got Error: $@\n";exit $exit_code;}exit $exit_code;}elsif ( $command eq "start" ) {my $exit_code = 10;eval {print "Enabling the VIP - $vip on the new master - $new_master_host \n";&start_vip();$exit_code = 0;};if ($@) {warn $@;exit $exit_code;}exit $exit_code;}elsif ( $command eq "status" ) {print "Checking the Status of the script.. OK \n";exit 0;}else {&usage();exit 1;}}sub start_vip() {`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;}sub stop_vip() {return 0 unless ($ssh_user);`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;}sub usage {print "Usage: master_ip_failover --command=start|stop|stopssh|status --ssh-user=user --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n"; }2.4 相关检测检测互信检查各节点互信是否正常，类似于之前的检查，此处有脚本实现检查[root@mha3 app1]# masterha_check_ssh --conf=/etc/masterha/app1.confSun May 24 17:33:08 2020 - [warning] Global configuration file /etc/masterha_f not found. Skipping.Sun May 24 17:33:08 2020 - [info] Reading application default configuration from /etc/masterha/app1.conf..Sun May 24 17:33:08 2020 - [info] Reading server configuration from /etc/masterha/app1.conf..Sun May 24 17:33:08 2020 - [info] Starting SSH connection tests..Sun May 24 17:33:12 2020 - [debug]Sun May 24 17:33:08 2020 - [debug] Connecting via SSH from root@192.168.28.131(192.168.28.131:22) to root@192.168.28.128(192.168.28.128:22)..Sun May 24 17:33:10 2020 - [debug] ok.Sun May 24 17:33:10 2020 - [debug] Connecting via SSH from root@192.168.28.131(192.168.28.131:22) to root@192.168.28.132(192.168.28.132:22)..Sun May 24 17:33:12 2020 - [debug] ok.Sun May 24 17:33:12 2020 - [debug]Sun May 24 17:33:08 2020 - [debug] Connecting via SSH from root@192.168.28.128(192.168.28.128:22) to root@192.168.28.131(192.168.28.131:22)..Sun May 24 17:33:09 2020 - [debug] ok.Sun May 24 17:33:09 2020 - [debug] Connecting via SSH from root@192.168.28.128(192.168.28.128:22) to root@192.168.28.132(192.168.28.132:22)..Sun May 24 17:33:12 2020 - [debug] ok.Sun May 24 17:33:13 2020 - [debug]Sun May 24 17:33:09 2020 - [debug] Connecting via SSH from root@192.168.28.132(192.168.28.132:22) to root@192.168.28.128(192.168.28.128:22)..Sun May 24 17:33:11 2020 - [debug] ok.Sun May 24 17:33:11 2020 - [debug] Connecting via SSH from root@192.168.28.132(192.168.28.132:22) to root@192.168.28.131(192.168.28.131:22)..Sun May 24 17:33:13 2020 - [debug] ok.Sun May 24 17:33:13 2020 - [info] All SSH connection tests passed successfully.检查复制集群是否正常如按照我之前的步骤配置，则此处会有如下异常masterha_check_repl --conf=/etc/masterha/app1.confSun May 24 17:34:02 2020 - [info] Connecting to root@192.168.28.131(192.168.28.131:22)..Can't exec "mysqlbinlog": No such file or directory at /usr/share/perl5/vendor_perl/MHA/BinlogManager.pm line 106.mysqlbinlog version command failed with rc 1:0, please verify PATH, LD_LIBRARY_PATH, and client optionsat /usr/bin/apply_diff_relay_logs line 532.报错信息很明确，找不到mysqlbinlog命令,处理⽅式⽐较简单，做个软连接即可ln -s /usr/local/mysql5.7/bin/mysql /usr/bin/ ln -s /usr/local/mysql5.7/bin/mysqlbinlog /usr/bin/再进⾏检测[root@mha3 app1]# masterha_check_repl --conf=/etc/masterha/app1.confSun May 24 17:34:41 2020 - [warning] Global configuration file /etc/masterha_f not found. Skipping.Sun May 24 17:34:41 2020 - [info] Reading application default configuration from /etc/masterha/app1.conf..Sun May 24 17:34:41 2020 - [info] Reading server configuration from /etc/masterha/app1.conf..Sun May 24 17:34:41 2020 - [info] MHA::MasterMonitor version 0.58.Sun May 24 17:34:42 2020 - [info] GTID failover mode = 0Sun May 24 17:34:42 2020 - [info] Dead Servers:Sun May 24 17:34:42 2020 - [info] Alive Servers:Sun May 24 17:34:42 2020 - [info] 192.168.28.128(192.168.28.128:3306)Sun May 24 17:34:42 2020 - [info] 192.168.28.131(192.168.28.131:3306)Sun May 24 17:34:42 2020 - [info] 192.168.28.132(192.168.28.132:3306)Sun May 24 17:34:42 2020 - [info] Alive Slaves:Sun May 24 17:34:42 2020 - [info] 192.168.28.131(192.168.28.131:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabledSun May 24 17:34:42 2020 - [info] Replicating from 192.168.28.128(192.168.28.128:3306)Sun May 24 17:34:42 2020 - [info] Primary candidate for the new Master (candidate_master is set)Sun May 24 17:34:42 2020 - [info] 192.168.28.132(192.168.28.132:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabledSun May 24 17:34:42 2020 - [info] Replicating from 192.168.28.128(192.168.28.128:3306)Sun May 24 17:34:42 2020 - [info] Not candidate for the new Master (no_master is set)Sun May 24 17:34:42 2020 - [info] Current Alive Master: 192.168.28.128(192.168.28.128:3306)Sun May 24 17:34:42 2020 - [info] Checking slave configurations..Sun May 24 17:34:42 2020 - [info] Checking replication filtering settings..Sun May 24 17:34:42 2020 - [info] binlog_do_db= , binlog_ignore_db=Sun May 24 17:34:42 2020 - [info] Replication filtering check ok.Sun May 24 17:34:42 2020 - [info] GTID (with auto-pos) is not supportedSun May 24 17:34:42 2020 - [info] Starting SSH connection tests..Sun May 24 17:34:48 2020 - [info] All SSH connection tests passed successfully.Sun May 24 17:34:48 2020 - [info] Checking MHA Node version..Sun May 24 17:34:49 2020 - [info] Version check ok.Sun May 24 17:34:49 2020 - [info] Checking SSH publickey authentication settings on the current master..Sun May 24 17:34:50 2020 - [info] HealthCheck: SSH to 192.168.28.128 is reachable.Sun May 24 17:34:51 2020 - [info] Master MHA Node version is 0.58.Sun May 24 17:34:51 2020 - [info] Checking recovery script configurations on 192.168.28.128(192.168.28.128:3306)..Sun May 24 17:34:51 2020 - [info] Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data/mysql3306/data --output_file=/tmp/save_binary_logs_test --manager_version=0.58 --start_file=mysql-bin.000012Sun May 24 17:34:51 2020 - [info] Connecting to root@192.168.28.128(192.168.28.128:22)..Creating /tmp if not exists.. ok.Checking output directory is accessible or not..ok.Binlog found at /data/mysql3306/data, up to mysql-bin.000012Sun May 24 17:34:52 2020 - [info] Binlog setting check done.Sun May 24 17:34:52 2020 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..Sun May 24 17:34:52 2020 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='mha' --slave_host=192.168.28.131 --slave_ip=192.168.28.131 --slave_port=3306 --workdir=/tmp --target_version=5.7.25-28-log --manager_version=0.5 Sun May 24 17:34:52 2020 - [info] Connecting to root@192.168.28.131(192.168.28.131:22)..Checking slave recovery environment settings..Opening /data/mysql3306/data/ ... ok.Relay log found at /data/mysql3306/data, up to relay-log.000003Temporary relay log file is /data/mysql3306/data/relay-log.000003 Checking if super_read_only is defined and turned on.. not present or turned off, ignoring.Testing mysql connection and privileges..mysql: [Warning] Using a password on the command line interface can be insecure.done.Testing mysqlbinlog output.. done.Cleaning up test file(s).. done.Sun May 24 17:34:53 2020 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='mha' --slave_host=192.168.28.132 --slave_ip=192.168.28.132 --slave_port=3306 --workdir=/tmp --target_version=5.7.25-28-log --manager_version=0.5 Sun May 24 17:34:53 2020 - [info] Connecting to root@192.168.28.132(192.168.28.132:22)..Checking slave recovery environment settings..Opening /data/mysql3306/data/ ... ok.Relay log found at /data/mysql3306/data, up to relay-log.000003Temporary relay log file is /data/mysql3306/data/relay-log.000003 Checking if super_read_only is defined and turned on.. not present or turned off, ignoring.Testing mysql connection and privileges..mysql: [Warning] Using a password on the command line interface can be insecure.done.Testing mysqlbinlog output.. done.Cleaning up test file(s).. done.Sun May 24 17:34:54 2020 - [info] Slaves settings check done.Sun May 24 17:34:54 2020 - [info]192.168.28.128(192.168.28.128:3306) (current master)+--192.168.28.131(192.168.28.131:3306)+--192.168.28.132(192.168.28.132:3306)Sun May 24 17:34:54 2020 - [info] Checking replication health on 192.168.28.131..Sun May 24 17:34:54 2020 - [info] ok.Sun May 24 17:34:54 2020 - [info] Checking replication health on 192.168.28.132..Sun May 24 17:34:54 2020 - [info] ok.Sun May 24 17:34:54 2020 - [info] Checking master_ip_failover_script status:Sun May 24 17:34:54 2020 - [info] /usr/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.28.128 --orig_master_ip=192.168.28.128 --orig_master_port=3306IN SCRIPT TEST====/sbin/ip addr del 192.168.28.199/24 dev ens33==/sbin/ip addr add 192.168.28.199/24 dev ens33===Checking the Status of the script.. OKSun May 24 17:34:54 2020 - [info] OK.Sun May 24 17:34:54 2020 - [warning] shutdown_script is not defined.Sun May 24 17:34:54 2020 - [info] Got exit code 0 (Not master dead).MySQL Replication Health is OK.看到 "MySQL Replication Health is OK." 代表检测通过。

MySQL高可用性大杀器之MHA

提到MySQL高可用性，很多人会想到MySQL Cluster，亦或者Heartbeat+DRBD，不过这些方案的复杂性常常让人望而却步，与之相对，利用MySQL复制实现高可用性则显得容易很多，目前大致有MMM，PRM，MHA等方案可供选择：MMM是最常见的方案，可惜它带来的问题往往比解决的问题还多（What’s wrong with MMM?）；至于PRM，它还是个新项目，暂时不推荐用于产品环境，不过作为Percona的作品，它值得期待；如此看来目前只能选MHA了，好在经过DeNA大规模的实践应用证明它是个靠谱的工具。

安装：作为前提条件，应先配置MySQL复制，并设置SSH公钥免密码登录。

下面以CentOS为例来说明，最好先安装EPEL，不然YUM可能找不到某些软件包。

MHA由Node和Manager组成，Node运行在每一台MySQL服务器上，也就是说，不管是MySQL主服务器，还是MySQL从服务器，都要安装Node，而Manager通常运行在独立的服务器上，但如果硬件资源吃紧，也可以用一台MySQL从服务器来兼职Manager的角色。

安装Node：shell> yum install perl-DBD-MySQLshell> rpm -Uvh/files/mha4mysql-node-0.52-0.noa rch.rpm安装Manager：shell> yum install perl-DBD-MySQLshell> yum install perl-Config-Tinyshell> yum install perl-Log-Dispatchshell> yum install perl-Parallel-ForkManagershell> rpm -Uvh/files/mha4mysql-node-0.52-0.noa rch.rpmshell> rpm -Uvh/files/mha4mysql-manager-0.52-0. noarch.rpm配置：配置全局设置：shell> cat /etc/masterha_f[server default]user=...password=...ssh_user=...配置应用设置：shell> cat /etc/masterha_f[server_1]hostname=...[server_2]hostname=...注：MHA配置文件中参数的详细介绍请参考官方文档。

魅族资深DBA：利用MHA构建MySQL高可用平台

魅族资深DBA：利用MHA构建MySQL高可用平台本次分享主要包括以下几方面：如何利用MHA改造MHA适应MySQL高可用场景构建MySQL高可用平台的出发点如何构建MySQL高可用平台一、背景和目标1. 以前几十台DB服务器，人工登陆服务器就能维护好，也没有高可用，当master挂了，通知业务将IP切换到slave然后重启也能基本满足业务要求，但是业务迅速发展，实例数不断增加，复制集不断增加，数据库架构多样化，而这种人工维护方式显然大大增加了DBA工作量，而且效率低下、容易出错。

2. DB规模的增大，机器故障、SQL故障、实例故障出现的概率也增加、还有来自业务方的DB变更，比如大表增加字段、增加索引、批量删除数据等异常维护操作，当然这些在一定条件下可用采用在线变更，比如采用pt-online-schema-change工具，但是当不满足在线变更条件、或者在线变更复杂的情况下，就需要采用滚动变更的方式，先在各个slave上变更、在线切换后再在master上变更，然后再进行一次切换还原，而这些切换操作如果全部手工敲命令来进行显然是不可取的。

3. 随着用户数的不断增加，业务方对DB这种基础服务的可用性也就越来越高，在魅族业务对DB的可用性要求是每个月需要达到四个9，也就意味着每个月的故障时间只有不到5分钟，以前那种通知业务更改IP重启的方式显然是达不到这个要求的。

在这些背景和要求下，我们需要摆脱手工操作，需要一套有效的MySQL高可用方案和一个高效的高可用平台来支撑DB的快速增长。

MySQL高可用平台需要达到的目标有以下几点：1. 数据一致性保证这个是最基本的同时也是前提，如果主备的数据的不一致，那么切换就无法进行，当然这里的一致性也是一个相对的，但是要做到最终一致性。

2. 故障快速切换，当master故障时这里可以是机器故障或者是实例故障，要确保业务能在最短时间切换到备用节点，使得业务受影响时间最短。

基于MHA的MySQL高可用方案

基于MHA的MySQL⾼可⽤⽅案⼀、前期环境部署1、配置所有主机名称111：hostname server01bash112：hostname server02bash113：hostname server03bash114：hostname server04bash115：hostname server05bash2、配置所有主机名映射115：vim /etc/hosts 添加以下内容：192.168.200.111 server01192.168.200.112 server02192.168.200.113 server03192.168.200.114 server04192.168.200.115 server05发送给其他主机：scp /etc/hosts 192.168.200.111:/etc/scp /etc/hosts 192.168.200.112:/etc/scp /etc/hosts 192.168.200.113:/etc/scp /etc/hosts 192.168.200.114:/etc/3、所有主机关闭防⽕墙和安全机制systemctl stop iptablessystemctl stop firewalldsetenforce 04、上传mha-manager 和 mha-node115：上传三个111、112、113、114上传两个⼆、安装MHA node1、所有主机安装 MHA node 及相关 perl 依赖包安装 epel 源:rpm -ivh epel-release-latest-7.noarch.rpmyum install -y perl-DBD-MySQL.x86_64 perl-DBI.x86_64 perl-CPAN perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker 注意：安装后建议检查⼀下所需软件包是否全部安装：rpm -q perl-DBD-MySQL.x86_64 perl-DBI.x86_64 perl-CPAN perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker2、所有主机上安装 MHA Nodetar xf mha4mysql-node-0.56.tar.gzcd mha4mysql-node-0.56/perl Makefile.PLmake && make install3、MHA Node 安装完后会在 /usr/local/bin ⽣成以下脚本ls -l /usr/local/bin/三、安装MHA Manger（115）注意：安装 MHA Manger 之前也需要安装 MHA Node1、⾸先安装 MHA Manger 依赖的 perl 模块（我这⾥使⽤ yum 安装）yum install -y perl perl-Log-Dispatch perl-Parallel-ForkManager perl-DBD-MySQL perl-DBI perl-Time-HiResyum -y install perl-Config-Tiny-2.14-7.el7.noarch.rpm检查有没有安装上：rpm -q perl perl-Log-Dispatch perl-Parallel-ForkManager perl-DBD-MySQL perl-DBI perl-Time-HiRes perl-Config-Tiny 2、安装 MHA Manger 软件包tar xf mha4mysql-manager-0.56.tar.gzcd mha4mysql-manager-0.56/perl Makefile.PLmake && make install3、安装完成之后会⽐之前多出⼀些的脚本⽂件ls -l /usr/local/bin/四、配置 SSH 密钥对验证服务器之间需要实现密钥对验证。

MySQL高可用之MHA的实现及大规模运维实践

Slave1
Slave2
5.Apply to 10.Reset slave info 8.并行Apply
4.生成 4.生成
Slave3
8.并行Apply
1.New Master Diff relaylog1
Diff relaylog2
+
Diff Binlog
30
Online切换
检查配置 stop start
4
项目介绍及Wiki
5
MHA架构
Manager
Master
监控机
推荐
S1
S2
Sn
6
Manager
Master1
Master2
两主多从
multi_tier_slave=1 MHA 0.52
监控机
S1.1
S1.2
S2.1
S2.2
7
MHA组集中化管理
MHA Manager
Master
slave1
slave2
9.MHA切换流程
10.对MHA的改进
11.我们遇到的问题及解决方法
3
MHA简介
全称：Master High Available Manager 开源：https:///p/mysql-master-ha/ 语言：perl 关于作者：http://yoshinorimatsunobu.blogspot.jp
Master
binlog.000010 Pos:930
binlog
S1
relaybin.000003 Pos:1000 binlog.000010 Pos:730
Relay log
S2
relaybin.000005 Pos:960 binlog.000010 Pos:830

使用MHA实现MYSQL主从复制高可用

使用MHA实现MYSQL主从复制高可用MHA（Master High Availability）是一个用于管理MySQL主从复制环境的工具，它可以实现MySQL主从复制的自动切换和故障恢复。

在本文中，我们将介绍如何使用MHA来实现MySQL主从复制的高可用。

首先，我们需要准备一个MySQL主从复制的环境。

我们需要至少两台服务器，一台作为主服务器（Master），另外一台作为从服务器（Slave）。

在开始之前，确保能够正确设置主从数据库的复制。

MHA的基本原理是监控主服务器的状态，当主服务器发生故障时，自动将从服务器切换为主服务器，以实现高可用。

下面是实现MySQL主从复制高可用的步骤：2.配置MHA[server default]manager_log=/var/log/masterha/manager.logmanager_workdir=/var/log/masterha/manager_pid=/var/run/mha_manager.pid[server1]hostname=192.168.0.100candidate_master=1[server2]hostname=192.168.0.101candidate_master=1如上所示，我们需要配置manager_log、manager_workdir和manager_pid的路径，并在server default和每个服务器的部分配置主机名和候选主服务器。

3.配置SSH登录MHA需要通过SSH登录认证来管理MySQL主从复制环境。

因此，我们需要确保MHA服务器可以通过SSH登录到所有的主从服务器。

可以使用SSH密钥对来配置无密码登录，并确保正确设置每个服务器的SSH登录权限。

4.执行MHA的监控命令在MHA服务器上执行以下命令来启动MHA的监控程序：上面的命令中，--conf选项用于指定MHA的配置文件路径，--ignore_last_failover选项用于忽略上一次主从切换的状态。

mha 工作原理

mha 工作原理MHA，全称为MySQL High Availability，是一个用于提高MySQL数据库可用性的解决方案。

其工作原理如下：1. 主备复制：MHA通过在主数据库和备份数据库之间实现数据的同步复制来提供高可用性。

2. 监测和故障检测：MHA通过定期监测主数据库和备份数据库的状态来检测故障。

如果主数据库发生故障，MHA会自动将备份数据库提升为新的主数据库。

3. 故障切换：当主数据库发生故障时，MHA会自动将备份数据库提升为新的主数据库，并将原主数据库的数据同步到新的备份数据库中。

这样，系统可以在短时间内恢复，并继续提供服务。

4. 自动切换回复：当主数据库恢复正常时，MHA会自动将其重新变为主数据库，并将新的主数据库的数据同步到原备份数据库中，以实现数据一致性。

5. 自动故障恢复：MHA会自动处理主备数据库之间的数据同步和一致性，从而避免数据丢失和不一致的情况。

6. 监控和报警：MHA可以监控数据库的状态，并在发生故障或异常情况时发送报警通知，以便及时采取措施进行修复。

总之，MHA通过主备复制、故障检测、故障切换、自动切换回复、自动故障恢复以及监控和报警等机制，实现了MySQL 数据库的高可用性，确保系统在发生故障时能够迅速恢复并继续提供服务。

当MHA工作时，它主要基于以下几个组件和原理：1. MHA Manager：MHA Manager是MHA的核心组件，它负责监控主备数据库的状态，并根据预定义的策略和规则自动进行故障切换和恢复操作。

2. 主备同步复制：MHA使用MySQL的复制功能实现主备数据库之间的数据同步复制。

主库将更新操作记录在二进制日志（binlog）中，备库通过读取binlog并重放操作，从而保持主备数据库的数据一致性。

3. 心跳检测：MHA Manager通过定期向主备数据库发送心跳包来检测其状态。

如果发现主数据库无法正常响应，MHA Manager会判断主数据库发生了故障。

MySQL高可用的最佳应用与实践

MySQL高可用的最佳应用与实践一、常见的MySQL高可用架构MySQL高可用主要涉及两个方面，一是客户端如何切换，如何自动failover，二是多个MySQL节点之间如何做数据同步。

业界MySQL高可用的解决方案有很多，总结起来有几类：从客户端自动切换的角度来看主要有两类：一类是基于HA同步软件的MySQL高可用，用户通过VIP访问数据库，然后第三方组件监控MySQL的状态，控制VIP的漂移。

还有一类是基于API调用的MySQL高可用，把MySQL主从状态维护在客户端，应用程序可以通过API调用控制主从切换，进行数据同步。

MySQL多节点的数据同步方案也有多种，最常用的是基于binlog的数据同步，其次还有基于共享存储的数据同步，以及第三方自己实现的数据同步协议（如Galera）。

1、基于HA同步软件实现的高可用方案结构简单、容易管理；∙不支持多写、standby属于备机；∙不保证数据一致性；∙入侵性小，对用户透明。

2、MHA（Master High Availabitliy）下面，我们来介绍几种典型的MySQL HA同步软件。

在业界应用最为广泛，技术最为成熟的HA同步软件之一是MHA。

MHA全称是Master High Availability，是一种一主多从的数据库高可用解决方案。

他的特点是在保障高可用自切换的前提下，最大限度的保障主从数据的一致性。

我们先来看下MHA的架构图：1.保存故障的master节点的binlog日志;2.Manager查找最新更新的slave节点；3.应用差异的relay log日志到其他的slave；4.在slave节点上应用从master保存的binlog日志；5.提升一个slave为新的master；6.使其他的slave连接新的master进行复制。

4、基于API调用的MySQL高可用刚才介绍的两种MySQL高可用解决方案，主要都是基于VIP切换的，优点是对应用程序没有入侵，但是缺点是不够灵活，而且系统的可靠性取决于HA软件本身的可靠性。

MySQL高可用方案MHA的部署和原理

MySQL⾼可⽤⽅案MHA的部署和原理MySQL⾼可⽤⽅案MHA的部署和原理MHA概念简介MHA（Master High Availability）是⼀套相对成熟的MySQL⾼可⽤⽅案，能做到在0~30s内⾃动完成数据库的故障切换操作，在master服务器不宕机的情况下，基本能保证数据的⼀致性。

它由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

其中，MHA Manager可以单独部署在⼀台独⽴的机器上管理多个master-slave集群，也可以部署在⼀台slave上。

MHA Node则运⾏在每个mysql节点上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它⾃动将最新数据的slave提升为master，然后将其它所有的slave指向新的master。

在MHA⾃动故障切换过程中，MHA试图保存master的⼆进制⽇志，从⽽最⼤程度地保证数据不丢失，当这并不总是可⾏的，譬如，主服务器硬件故障或⽆法通过ssh访问，MHA就没法保存⼆进制⽇志，这样就只进⾏了故障转移但丢失了最新数据。

可结合MySQL 5.5中推出的半同步复制来降低数据丢失的风险。

MHA软件组成：Manager⼯具包和Node⼯具包，具体说明如下：MHA Manager：1. masterha_check_ssh：检查MHA的SSH配置状况2. masterha_check_repl：检查MySQL的复制状况3. masterha_manager：启动MHA4. masterha_check_status：检测当前MHA运⾏状态5. masterha_master_monitor：检测master是否宕机6. masterha_master_switch：控制故障转移（⾃动或⼿动）7. masterha_conf_host：添加或删除配置的server信息8. masterha_stop：关闭MHAMHA Node:save_binary_logs：保存或复制master的⼆进制⽇志apply_diff_relay_logs：识别差异的relay log并将差异的event应⽤到其它slave中filter_mysqlbinlog：去除不必要的ROLLBACK事件（MHA已不再使⽤这个⼯具）purge_relay_logs：消除中继⽇志（不会堵塞SQL线程）另有如下⼏个脚本需⾃定义：1. master_ip_failover：管理VIP2. master_ip_online_change：3. masterha_secondary_check：当MHA manager检测到master不可⽤时，通过masterha_secondary_check脚本来进⼀步确认，减低误切的风险。

mha mysql switchover 原理和步骤

mha mysql switchover 原理和步骤MHA（Master High Availability）是MySQL的高可用性解决方案，用于实现主从复制和故障切换。

MHA提供了自动化的故障切换功能，能够在主节点故障时自动将备节点提升为新的主节点，以保证数据库的高可用性。

MHA Switchover是MHA的一种操作，用于将一个备节点提升为新的主节点。

其原理和步骤如下：原理：MHA Switchover基于故障检测机制，通过检测主节点的状态来确定是否需要进行故障切换。

当检测到主节点故障时，MHA会自动将一个备节点提升为新的主节点，并将其他备节点作为新的从节点进行同步。

整个过程是自动化的，不需要人工干预。

步骤：1. 检测主节点状态：MHA通过监控机制定期检查主节点的状态，判断其是否正常工作。

如果主节点出现故障，MHA将启动故障切换流程。

2. 选择备节点：MHA会根据一定的算法选择一个健康的备节点作为新的主节点。

算法可以基于节点优先级、节点负载、节点距离等因素进行选择。

3. 提升备节点为主节点：MHA会自动将选定的备节点提升为新的主节点，并停止其从复制功能。

同时，MHA还会将其他备节点提升为新的从节点，并启动其从复制功能。

4. 同步数据：在提升备节点为主节点后，MHA会自动进行数据同步，确保新的主节点数据与原主节点一致。

同步过程中，MHA会根据实际情况进行数据合并或数据切分等操作。

5. 完成故障切换：当数据同步完成后，MHA会自动完成故障切换流程，将新的主节点作为数据库的入口点，提供数据库服务。

总之，MHA Switchover是一种自动化的故障切换机制，能够快速响应主节点故障，保证数据库的高可用性。

MySQL数据库的高可用性解决方案与部署

MySQL数据库的高可用性解决方案与部署随着互联网的迅猛发展，数据成为了企业最重要的资产之一。

而MySQL作为一种常用的关系型数据库，广泛应用于各个领域。

然而，由于数据库的单点故障可能导致业务中断，高可用性的需求变得尤为重要。

本文将重点讨论MySQL数据库的高可用性解决方案与部署。

一、高可用性的概念介绍高可用性（High Availability）指的是系统具有持续稳定运行的能力，即在面对硬件故障、软件问题或计划外的维护等情况下，仍然能够正常提供服务。

对于MySQL数据库而言，实现高可用性的关键在于确保数据库的持久性和可用性。

二、MySQL高可用性解决方案1. 主从复制（Master-Slave Replication）主从复制是MySQL中最为常见的高可用性解决方案之一。

通过配置一个主数据库（Master）和一个或多个从数据库（Slave），将主数据库的写操作同步到从数据库上。

在主数据库发生故障时，可以快速切换到从数据库，从而实现数据库的高可用性。

2. 主主复制（Master-Master Replication）与主从复制相比，主主复制可以实现双向的数据同步。

即每个节点既可以接受写操作，又可以读取数据。

这种解决方案在分布式系统中广泛应用，能够提高系统的并发性能和容错能力。

但需要注意的是，主主复制可能引发数据冲突和一致性问题，需要谨慎配置。

3. MHA（Master High Availability）MHA是由Mixi开发的一种自动化MySQL高可用性解决方案。

它基于主从复制原理，通过监控主库的状态来实现主从切换。

当主库出现故障时，MHA可以自动将从库切换为新的主库，并通知其他从库更改复制源。

MHA具有自动切换、故障检测和自动配置等特点，能够提供高可用性的MySQL服务。

4. Galera ClusterGalera Cluster是一个基于同步复制原理的MySQL高可用性解决方案，通过多个节点之间的同步复制来保证数据的一致性。

mha高可用原理

mha高可用原理MHA高可用原理MHA（Master High Availability）是一种MySQL高可用性解决方案，它可以确保MySQL主服务器的高可用性，同时提供快速的故障转移和自动故障恢复。

MHA的高可用原理是通过自动监控MySQL主服务器的状态，当主服务器出现故障时，自动将从服务器提升为新的主服务器，从而实现MySQL的高可用性。

MHA的高可用原理主要包括以下几个方面：1. 自动监控MySQL主服务器的状态MHA通过在MySQL主服务器和从服务器之间安装MHA节点，实现对MySQL主服务器的自动监控。

MHA节点会定期检查MySQL主服务器的状态，包括MySQL进程是否正常运行、MySQL主服务器是否能够连接到从服务器等。

如果MHA节点检测到MySQL主服务器出现故障，它会自动触发故障转移操作。

2. 快速的故障转移MHA的故障转移速度非常快，通常只需要几秒钟就可以完成。

当MHA节点检测到MySQL主服务器出现故障时，它会自动将从服务器提升为新的主服务器，并将其他从服务器重新连接到新的主服务器。

这样可以确保MySQL服务的连续性，避免因主服务器故障而导致的服务中断。

3. 自动故障恢复MHA不仅可以实现快速的故障转移，还可以自动恢复MySQL主服务器的正常运行。

当MHA节点检测到MySQL主服务器的故障已经被解决时，它会自动将主服务器恢复为原来的状态，并将从服务器重新连接到主服务器。

这样可以确保MySQL服务的稳定性和可靠性。

MHA的高可用原理是通过自动监控MySQL主服务器的状态，实现快速的故障转移和自动故障恢复，从而确保MySQL的高可用性。

MHA是一种非常实用的MySQL高可用性解决方案，可以帮助企业提高MySQL服务的可靠性和稳定性，避免因MySQL主服务器故障而导致的服务中断。

基于MHA的MySQL的高可用详细总结文档精品名师资料

文件版本：V1.0 文件编号：R&D0008编制：xxx发布日期：2016-08-10审批：MySQL MHA文档总结xxx 版权所有目录MySQL MHA介绍 (3)操作流程步骤 (4)拓扑图演变 (5)MHA软件包说明 (6)Manager工具包 (6)Node工具包 (7)实验环境 (7)建立ssh无密码登录环境 (7)manager 公约操作 (8)主mysql 公约操作 (8)从mysql1 公约操作 (8)从mysql2 公约操作 (9)主机名 (9)修改hosts (9)测试ssh登录 (10)安装mysql和配置主从关系 (10)在线安装mysql5.5 (10)编辑mysql配置文件 (11)启动mysql和查询启动状态 (11)数据库一致性 (12)半同步复制开启 (12)配置mysql主从 (13)测试mysql主从 (14)部署MHA (15)安装MHA Node (15)安装MHA manager (16)检查SSH配置 (18)检查复制情况 (18)启动MHA manager (21)停止MHA manager (21)任务计划 (21)配置vip (22)测试MHA (23)停止主mysql (24)查看从mysql情况 (24)资料（源码包/配置文件） (25)参考文章 (25)FAQ (26)修订记录版本号发布日期拟制人修订描述V1.0 2016-08-10 xxx 首次发布MySQL MHA MySQL MHA介绍实现原理：MHA是由日本Mysql专家用Perl写的一套Mysql故障切换方案以保障数据库的高可用性，它的功能是能在0-30s之内实现主Mysql故障转移（failover），MHA故障转移可以很好的帮我们解决从库数据的一致性问题，同时最大化挽回故障发生后的数据。

MHA里有两个角色一个是node节点一个是manager节点，要实现这个MHA，必须最少要三台数据库服务器，一主多备，即一台充当master，一台充当master的备份机，另外一台是从属机，这里实验为了实现更好的效果使用四台机器，需要说明的是一旦主服务器宕机，备份机即开始充当master提供服务，如果主服务器上线也不会再成为master了，因为如果这样数据库的一致性就被改变了。

简述mha工作原理

简述mha工作原理
MHA（MySQL高可用性架构）是一种用于MySQL数据库的高可用性解决方案。

它的工作原理是通过将多个MySQL实例组成一个集群，实现数据库的高可用性和负载均衡。

MHA的核心组件包括MHA Manager和MHA Node。

MHA Manager 是集群管理器，负责监控MySQL实例的状态，并在主节点故障时自动切换到备用节点。

MHA Node是集群节点，负责处理MySQL实例的复制和同步。

MHA的工作流程如下：
1. MHA Manager监控MySQL实例的状态，包括主节点和备用节点。

2. 当主节点发生故障时，MHA Manager会自动将备用节点提升为主节点，并将其他节点的复制和同步指向新的主节点。

3. MHA Manager会在新的主节点上执行一系列操作，包括更新DNS记录、修改VIP地址等，以确保客户端能够正确地连接到新的主节点。

4. 当主节点恢复正常时，MHA Manager会将其重新加入集群，并将其设置为备用节点。

MHA的优点在于它能够快速地检测和处理MySQL实例的故障，从而保证数据库的高可用性和可靠性。

此外，MHA还支持多种故障检
测方式，包括ping、SSH、MySQL心跳等，可以根据实际情况选择最适合的方式。

MHA是一种非常实用的MySQL高可用性解决方案，它的工作原理简单明了，易于部署和维护。

对于需要保证数据库高可用性的企业来说，MHA是一个不错的选择。

mysql的mha高可用原理

MHA高可用原理1. 概述MHA（Master High Availability）是一种用于MySQL数据库的高可用解决方案，它通过自动监控和管理MySQL主从复制环境中的主节点切换，实现了数据库的高可用性和故障转移。

MHA采用了多个关键技术和组件，包括监控器（Monitor）、管理器（Manager）和脚本工具（Tools）。

其中监控器负责监控主节点的状态，管理器负责进行主从切换操作，脚本工具则提供了一些辅助功能。

在MHA架构中，有一个专门的服务器作为监控节点，称为MHA Manager。

它通过SSH连接到每个MySQL服务器，并定期检查它们的状态。

当发现主节点出现故障时，MHA Manager会自动将一个从节点提升为新的主节点，并将其他从节点重新配置为新的主节点的从节点。

2. MHA架构MHA架构由以下几个组件组成：2.1 MHA ManagerMHA Manager是整个系统的核心组件，它负责监控MySQL服务器、执行主从切换操作以及协调其他组件之间的通信。

MHA Manager通常在单独的服务器上运行，并通过SSH连接到每个MySQL服务器。

2.2 MHA NodeMHA Node是一个运行在MySQL服务器上的代理程序，它负责与MHA Manager进行通信，并执行由MHA Manager下发的命令。

MHA Node通过监控MySQL二进制日志（binlog）来获取主节点的更新，并将其应用到从节点上。

2.3 MHA MonitorMHA Monitor是一个独立的监控程序，它定期检查MySQL服务器的状态，并将状态信息发送给MHA Manager。

MHA Monitor可以使用多种方式进行检测，包括ping、TCP连接和执行SQL查询等。

3. MHA工作原理下面详细介绍了MHA在实现高可用性和故障转移方面的工作原理：3.1 主节点监控MHA Monitor定期向每个MySQL服务器发送心跳包，以检测其存活状态。

MySQL之MHA高可用配置及故障切换实现详细部署步骤

MySQL之MHA⾼可⽤配置及故障切换实现详细部署步骤⽬录⼀、MHA介绍（⼀）、什么是MHA（⼆）、MHA 的组成（三）、MHA 的特点⼆、搭建 MySQL MHA（⼀）、实验思路：（⼆）、实验步骤（三）、故障模拟⼀、MHA介绍（⼀）、什么是MHAMHA（MasterHigh Availability）是⼀套优秀的MySQL⾼可⽤环境下故障切换和主从复制的软件。

MHA 的出现就是解决MySQL 单点的问题。

MySQL故障切换过程中，MHA能做到0-30秒内⾃动完成故障切换操作。

MHA能在故障切换的过程中最⼤程度上保证数据的⼀致性，以达到真正意义上的⾼可⽤。

（⼆）、MHA 的组成MHA Node（数据节点）MHA Node 运⾏在每台 MySQL 服务器上。

MHA Manager（管理节点）MHA Manager 可以单独部署在⼀台独⽴的机器上，管理多个 master-slave 集群；也可以部署在⼀台 slave 节点上。

MHA Manager 会定时探测集群中的 master 节点。

当 master 出现故障时，它可以⾃动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。

整个故障转移过程对应⽤程序完全透明。

（三）、MHA 的特点⾃动故障切换过程中，MHA试图从宕机的主服务器上保存⼆进制⽇志，最⼤程度的保证数据不丢失使⽤半同步复制，可以⼤⼤降低数据丢失的风险，如果只有⼀个slave已经收到了最新的⼆进制⽇志，MHA可以将最新的⼆进制⽇志应⽤于其他所有的slave服务器上，因此可以保证所有节点的数据⼀致性⽬前MHA⽀持⼀主多从架构，最少三台服务，即⼀主两从⼆、搭建 MySQL MHA（⼀）、实验思路：1．MHA架构1）数据库安装2）⼀主两从3）MHA搭建2．故障模拟1）主库失效2）备选主库成为主库3）原故障主库恢复重新加⼊到MHA成为从库（⼆）、实验步骤MHA manager 节点服务器：CentOS7.4(64 位) manager/192.168.126.10 ，安装MHA node 和 manager 组件Master 节点服务器：CentOS7.4(64 位) mysql1/192.168.126.20 ，安装mysql5.7、MHA node 组件Slave1 节点服务器：CentOS7.4(64 位) mysql2/192.168.126.30，安装mysql5.7、MHA node 组件Slave2 节点服务器：CentOS7.4(64 位) mysql3/192.168.126.40，安装mysql5.7、MHA node 组件每台机⼦关闭防⽕墙systemctl stop firewalldsystemctl disable firewalldsetenforce 01、安装mysql15.7Master、Slave1、Slave2 节点上安装 mysql5.7 （mysql安装详见前期博⽂）2、修改 Master、Slave1、Slave2 节点的主机名hostnamectl set-hostname Mysql1hostnamectl set-hostname Mysql2hostnamectl set-hostname Mysql33、修改 Master、Slave1、Slave2 节点的 Mysql主配置⽂件/etc/f##Master 节点##vim /etc/f[mysqld]server-id = 1log_bin = master-binlog-slave-updates = truesystemctl restart mysqld##Slave1、Slave2 节点##vim /etc/fserver-id = 2 #三台服务器的 server-id 不能⼀样log_bin = master-binrelay-log = relay-log-binrelay-log-index = slave-relay-bin.indexsystemctl restart mysqld4．在 Master、Slave1、Slave2 节点上都创建两个软链接ln -s /usr/local/mysql/bin/mysql /usr/sbin/ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/5．配置 mysql ⼀主两从（1）所有数据库节点进⾏ mysql 授权mysql -uroot -pgrant replication slave on *.* to 'myslave'@'192.168.126.%' identified by '123'; #从数据库同步使⽤grant all privileges on *.* to 'mha'@'192.168.126.%' identified by 'manager'; #manager 使⽤grant all privileges on *.* to 'mha'@'Mysql1' identified by 'manager'; #防⽌从库通过主机名连接不上主库grant all privileges on *.* to 'mha'@'Mysql2' identified by 'manager';grant all privileges on *.* to 'mha'@'Mysql3' identified by 'manager';flush privileges;（2）在 Master 节点查看⼆进制⽂件和同步点show master status;（3）在 Slave1、Slave2 节点执⾏同步操作change master to master_host='192.168.126.20',master_user='myslave',master_password='123',master_log_file='master-bin.000001',master_log_pos=1747; start slave;（4）在 Slave1、Slave2 节点查看数据同步结果show slave status\G//确保 IO 和 SQL 线程都是 Yes，代表同步正常。

探索MySQL高可用架构之MHA

探索 MySQL 高可用架构之 MHAMHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，它由日本 DeNA 公司 youshimaton （现就职于 Facebook 公司）开发，是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。

在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

AD：本文出自 51CTO 博客博主走不完的路,看不完的书! ，如有任何问题请进入博主页面互动讨论。

博文地址：/3549599/1664138什么是高可用性? 很多公司的服务都是 24 小时*365 天不间断的。

比如 Call Center。

这就要求高可用性。

再比如购物网站，必须随时都可以交易。

那么当购物网的 server 挂了一个的时候，不能对业务产生任何影响。

这就是高可用性。

如何处理 failover? 解释 failover，意思就是当服务器 down 掉，或者出现错误的时候，可以自动的切换到其他待命的服务器，不影响服务器上 App 的运行。

以 MySQL 为例,什么样的架构才能保证其高可用性呢? MySQL replication with manual failover 同步数据是采用 MySQL replication 的方法，在 MySQL 分表分块到主从已经解释。

简单的说就是从库根据主库的日志来做相应的处理，保证数据的一致。

通常还配合 MySQL Proxy 或 Amoeba 等进行读写分离减少服务器压力。

manual failover，显然当 Master 挂掉时，利用本方式是需要手动来处理 failover，一般来说是将 slave 更改为 server。

【尚择优选】基于MHA的MySQL的高可用详细总结文档

MySQLMHA文档总结修订记录MySQLMHAMySQLMHA介绍实现原理：MHA是由日本Mysql专家用Perl写的一套Mysql故障切换方案以保障数据库的高可用性，它的功能是能在0-30s之内实现主Mysql故障转移（failover），MHA故障转移可以很好的帮我们解决从库数据的一致性问题，同时最大化挽回故障发生后的数据。

该软件由两部分组成：MHAManager（管理节点）和MHANode（数据节点）。

MHAManager可以单独部署在一台独立的机器上管理多个master-slave 集群，也可以部署在一台slave节点上。

MHANode运行在每台MySQL服务器上，MHAManager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave 重新指向新的master。

整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。

例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。

使用MySQL5.5的半同步复制，可以大大降低数据丢失的风险。

MHA可以与半同步复制结合起来。

如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

mha高可用集群原理

mha高可用集群原理MHA（Master High Availability）是一种用于MySQL数据库的高可用性解决方案，通过实现数据库的主-从复制和自动主备切换，保证数据库的高可用性和故障恢复能力。

MHA集群原理如下：1.主-从复制：MHA通过在主节点和备节点之间设置MySQL的主-从复制来实现数据的复制和同步。

主节点负责处理所有写操作，而备节点则负责同步主节点的数据。

2.MHA Manager：MHA集群通过一个称为MHA Manager的组件来管理主备节点之间的复制和自动切换。

MHAManager负责监测主节点的状态，并在主节点发生故障时自动选择一个备节点作为新的主节点。

3.心跳监测：MHA集群使用心跳监测来检测主节点的状态。

心跳监测通过在主节点和备节点之间定期发送心跳包来确认主节点的健康状态。

如果心跳监测检测到主节点不可用，MHA Manager将触发自动切换操作。

4.自动主备切换：当MHA Manager检测到主节点故障时，它会根据事先配置的规则，自动选择一个备节点来作为新的主节点。

然后，MHA Manager更新所有其他备节点的配置文件，使用新的主节点的地址进行复制和同步。

5.IP漂移：为了实现透明的主备切换，MHA使用IP漂移技术。

当主备切换发生时，MHA Manager会对IP地址进行更新，将新的主节点的IP地址分配给原来的主节点。

这样，应用程序可以继续使用相同的IP地址连接到数据库，而无需进行手动更改。

总结起来，MHA集群通过主-从复制、MHA Manager、心跳监测、自动主备切换和IP漂移等技术，实现MySQL数据库的高可用性和故障恢复能力。

这种集群架构可以保证数据库的连续可用性，并减少人为的干预和维护成本。