MySQL基于MHA高可用理论篇,白屏化背后

2019-07-25 09:19栏目:科技传媒

作者介绍茹作军,曾任职我查查运维工程师、1号店MySQL DBA,现就职于平安好医生。Lepus开源数据库监控系统作者(www.lepus.cc)。

3.4.9.验证并启动manager进程
$ masterha_check_ssh --conf=/etc/mha/app3389.cnf 
Wed Nov 22 07:35:07 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Nov 22 07:35:07 2017 - [info] Reading application default configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:35:07 2017 - [info] Reading server configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:35:07 2017 - [info] Starting SSH connection tests..
Wed Nov 22 07:35:08 2017 - [debug] 
Wed Nov 22 07:35:07 2017 - [debug]  Connecting via SSH from root@192.168.217.130(192.168.217.130:22) to root@192.168.217.131(192.168.217.131:22)..
Wed Nov 22 07:35:08 2017 - [debug]   ok.
Wed Nov 22 07:35:08 2017 - [debug] 
Wed Nov 22 07:35:07 2017 - [debug]  Connecting via SSH from root@192.168.217.131(192.168.217.131:22) to root@192.168.217.130(192.168.217.130:22)..
Wed Nov 22 07:35:08 2017 - [debug]   ok.
Wed Nov 22 07:35:08 2017 - [info] All SSH connection tests passed successfully.

$ masterha_check_repl --conf=/etc/mha/app3389.cnf 
Wed Nov 22 07:47:07 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Nov 22 07:47:07 2017 - [info] Reading application default configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:47:07 2017 - [info] Reading server configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:47:07 2017 - [info] MHA::MasterMonitor version 0.57.
Wed Nov 22 07:47:08 2017 - [info] GTID failover mode = 1
Wed Nov 22 07:47:08 2017 - [info] Dead Servers:
Wed Nov 22 07:47:08 2017 - [info] Alive Servers:
Wed Nov 22 07:47:08 2017 - [info]   192.168.217.130(192.168.217.130:3389)
Wed Nov 22 07:47:08 2017 - [info]   192.168.217.131(192.168.217.131:3389)
Wed Nov 22 07:47:08 2017 - [info] Alive Slaves:
Wed Nov 22 07:47:08 2017 - [info]   192.168.217.131(192.168.217.131:3389)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Wed Nov 22 07:47:08 2017 - [info]     GTID ON
Wed Nov 22 07:47:08 2017 - [info]     Replicating from 192.168.217.130(192.168.217.130:3389)
Wed Nov 22 07:47:08 2017 - [info]     Primary candidate for the new Master (candidate_master is set)
Wed Nov 22 07:47:08 2017 - [info] Current Alive Master: 192.168.217.130(192.168.217.130:3389)
Wed Nov 22 07:47:08 2017 - [info] Checking slave configurations..
Wed Nov 22 07:47:08 2017 - [info]  read_only=1 is not set on slave 192.168.217.131(192.168.217.131:3389).
Wed Nov 22 07:47:08 2017 - [info] Checking replication filtering settings..
Wed Nov 22 07:47:08 2017 - [info]  binlog_do_db= , binlog_ignore_db= 
Wed Nov 22 07:47:08 2017 - [info]  Replication filtering check ok.
Wed Nov 22 07:47:08 2017 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Warning: Permanently added '192.168.217.132' (RSA) to the list of known hosts.
Wed Nov 22 07:47:08 2017 - [info] HealthCheck: SSH to 192.168.217.132 is reachable.
Wed Nov 22 07:47:14 2017 - [info] Binlog server 192.168.217.132 is reachable.
Wed Nov 22 07:47:14 2017 - [info] Checking recovery script configurations on 192.168.217.132(192.168.217.132:3306)..
Wed Nov 22 07:47:14 2017 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data1/mha/binlog/3389 --output_file=/data1/mha/masterha/app3389/save_binary_logs_test --manager_version=0.57 --start_file=2171303389-bin.000003 
Wed Nov 22 07:47:14 2017 - [info]   Connecting to root@192.168.217.132(192.168.217.132:22).. 
  Creating /data1/mha/masterha/app3389 if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /data1/mha/binlog/3389, up to 2171303389-bin.000003
Wed Nov 22 07:47:14 2017 - [info] Binlog setting check done.
Wed Nov 22 07:47:14 2017 - [info] Checking SSH publickey authentication settings on the current master..
Wed Nov 22 07:47:15 2017 - [info] HealthCheck: SSH to 192.168.217.130 is reachable.
Wed Nov 22 07:47:15 2017 - [info] 
192.168.217.130(192.168.217.130:3389) (current master)
  --192.168.217.131(192.168.217.131:3389)

Wed Nov 22 07:47:15 2017 - [info] Checking replication health on 192.168.217.131..
Wed Nov 22 07:47:15 2017 - [info]  ok.
Wed Nov 22 07:47:15 2017 - [info] Checking master_ip_failover_script status:
Wed Nov 22 07:47:15 2017 - [info]   /etc/mha/master_ip_failover.sh 192.168.217.201  1 --command=status --ssh_user=root --orig_master_host=192.168.217.130 --orig_master_ip=192.168.217.130 --orig_master_port=3389 
Checking the Status of the script.. OK 
Wed Nov 22 07:47:15 2017 - [info]  OK.
Wed Nov 22 07:47:15 2017 - [info] Checking shutdown script status:
Wed Nov 22 07:47:15 2017 - [info]   /etc/mha/power_manager --command=status --ssh_user=root --host=192.168.217.130 --ip=192.168.217.130 
Wed Nov 22 07:47:15 2017 - [info]  OK.
Wed Nov 22 07:47:15 2017 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

$ nohup masterha_manager --conf=/etc/mha/app3389.cnf --ignore_last_failover &
[2] 7307
$ nohup: ignoring input and appending output to `nohup.out'

$ masterha_check_status --conf=/etc/mha/app3389.cnf 
app3389 (pid:7307) is running(0:PING_OK), master:192.168.217.130

MySQL高可用系统

MySQL高可用,顾名思义就是当MySQL主机或服务发生任何故障时能够立马有其他主机顶替其工作,并且最低要求是要保证数据一致性。因此,对于一个MySQL高可用系统需要达到的目标有以下几点:

(1)、数据一致性保证这个是最基本的同时也是前提,如果主备的数据不一致,那么切换就无法进行,当然这里的一致性也是一个相对的,但是要做到最终一致性。

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

(3)、简化日常维护,通过高可用平台来自动完成高可用的部署、维护、监控等任务,能够最大程度的解放DBA手动操作,提高日常运维效率。

(4)、统一管理,当复制集很多的情况下,能够统一管理高可用实例信息、监控信息、切换信息等。

(5)、高可用的部署要对现有的数据库架构无影响,如果因为部署高可用,需要更改或者调整数据库架构则会导致成本增加。

目前MySQL高可用方案可以一定程度上实现数据库的高可用,比如MMM,heartbeat drbd,NDB Cluster等。还有MariaDB的Galera Cluster,以及MySQL 5.7.17 Group Replication等。这些高可用软件各有优劣。在进行高可用方案选择时,主要是看业务对数据一致性方面的要求。最后出于对数据库的高可用和高可靠的要求,目前推荐使用MHA架构,因为MySQL GP还不能在生产使用,但是相信以后慢慢就会被用到生产环境的。

数据库安装路径:

图片 1

MHA工作流程

下图展示了如何通过MHA Manager管理多组主从复制,可以将MHA工作原理总结为如下:

图片 2

1、MHA如何监控master和故障转移?

1.1 验证复制设置以及确认当前master状态

连接所有hosts,MHA自动来确认当前master是哪个,配置文件中无需指定哪个是master。

如果其中有任何一个slave挂了,脚本立即退出,停止监控。

如果有一些必要的脚本没有在MHA Node节点安装,那么MHA在这个阶段终止,且停止监控。

1.2 监控master

监控master,直到master挂了。

这个阶段,MHA不会监控slave,Stopping/Restarting/Adding/Removing操作在slave上,不会影响当前的MHA监控进程。当你添加或者删除slave的时候,请更新好配置文件,最好重启MHA。

1.3 检测master是否失败

如果MHA Manger三次间隔时间都没办法连接master server,就会进入这个阶段。

如果你设置了secondary_check_script ,那么MHA会调用脚本做二次检测来判断master是否是真的挂了。

接下来的步骤,就是masterha_master_switch的工作流程了。

1.4 再次验证slave的配置

如果发现任何不合法的复制配置(有些slave的master不是同一个),那么MHA会停止监控,且报错。可以设置ignore_fail忽略。

这一步是处于安全考虑,很有可能,复制的配置文件已经被改掉了,所以double check是比较推荐的做法。

检查最后一次failover(故障转移)的状态

如果上一次的failover报错,或者上一次的failover结束的太近(默认3天),MHA停止监控,停止failover,那么在masterha_manager命令中设置ignore_last_failover,wait_on_failover_error来改变这一检测。这么做,也是出于安全考虑。频繁的failover,检查下是否网络出问题,或者其他错误呢?

1.5 关掉失败的master的服务器(可选)

如果在配置文件中定义了master_ip_failover_script and/or shutdown_script ,MHA会调用这些的脚本。

关闭dead master,避免脑裂(值得商榷)。

1.6 恢复一台新master

从crashed master服务器上保存binlog到Manager(如果可以的话

如果dead master可以SSH的话,拷贝binary logs从最新的slave上的end_log_pos(Read_Master_Log_Pos)位置开始拷贝。

选举新master

一般根据配置文件的设置来决定选举谁,如果想设置一些候选master,设置candidate_master=1;如果想设置一些host,永远都不会选举,设置no_master=1;确认最新的slave (这台slave拥有最新的relay-log)。

恢复和提升新master

根据老master binlog生成差异日志,应用日志到new master,如果这一步发生错误(如:duplicate key error),MHA停止恢复,并且其余的slave也停止恢复。

2)MHA如何在线快速切换master?

下面的步骤,就是masterha_master_switch—master_state=alive做的事情。

2.1 验证复制设置以及确认当前master状态

连接配置文件中列出的所有hosts,MHA自动来确认当前master是哪个,配置文件中无需指定哪个是master。

执行 flush tables 命令在master上(可选). 这样可以缩短FLUSH TABLES WITH READ LOCK的时间。

既不监控master,也不会failover。

检查下面的条件是否满足。

A. IO线程是否在所有slave上都是running。

B. SQL线程是否在所有slave上都是running。

C. Seconds_Behind_Master 是否低于2秒(—running_updates_limit=N)。

D. master上是否没有长的更新语句大于2秒。

2.2 确认新master

新master需要设置: –new_master_host参数。

原来的master和新的master必须要有同样的复制过滤条件(binlog-do-db and binlog-ignore-db)。

2.3 当前master停写

如果你在配置中定义了master_ip_online_change_script,MHA会调用它。可以通过设置SET GLOBAL read_only=1来完美的阻止写入。

在老master上执行FLUSH TABLES WITH READ LOCK来阻止所有的写(–skip_lock_all_tables可以忽略这一步)。

2.4 等待其他slave追上当前master,同步无延迟

调用这个函数MASTER_LOG_POS()。

2.5 确保新master可写

执行SHOW MASTER STATUS来确定新master的binary log文件名和position。

如果设置了master_ip_online_change_script,会调用它。可以创建写权限的用户,SET GLOBAL read_only=0。

2.6 让其他slave指向新master

并行执行CHANGE MASTER, START SLAVE。

图片 3

3.3.4.主库传输至从库
# scp /data1/tmp/full_3389.tar.gz 192.168.217.131:/data1/tmp

MHA技术介绍

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。除了failover之外,MHA还支持在线master切换,非常安全和高效,大概只需要(0.5 ~ 2秒)的阻塞写时间。

该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当slave。当然,如果你处于成本考虑,也可以使用两个节点的MHA,一主一从(实测过的)。

总结一下,MHA提供了如下功能:

(1)master自动监控,故障转移一体化(Automated master monitoring and failover)

(2)MHA可以在一个复制组中监控master的状态,如果挂了,就可以自动的做failover。

(3)MHA通过所有slave的差异relay-log来保证数据的一致性。

(4)MHA在做故障转移,日志补偿这些动作的时候,通常只需要10~30秒。

(5)通常情况下,MHA会选择最新的slave作为new master,但是你也可以指定哪些是候选maser,那么新master选举的时候,就从这些host里面挑。

(6)导致复制环境中断的一致性问题,在MHA中是不会发生的,请放心使用。

在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据。使用MySQL 5.5及以上版本的半同步复制,可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。

(7)手工-交互式master故障转移(Interactive manually initiated Master Failover)

MHA可以配置成手工-交互式方式进行故障转移,不支持监控master的状态。

(8)非交互式master故障转移 (Non-interactive master failover)

非交互式,自动的故障转移,不提供监控master状态功能,监控可以交给其他组件做(如:Pacemaker heartbeat)。

(9)在线master切换 (Online switching master to a different host)

如果你有更快,更好的master,计划要将老master替换成新的master,那么这个功能特别适合这样的场景。

这不是master真的挂掉了,只是我们有很多需求要进行master例行维护。

MHA的优点

  1. master failover和slave promotion非常快速。

2. 自动探测,多重检测,切换过程中支持调用其他脚本的接口。

  1. master crash不会导致数据不一致,自动补齐数据,维护数据一致性。

  2. 不需要修改复制的任何设置,简单易部署,对现有架构无影响。

  3. 不需要增加很多额外的机器来部署MHA,支持多实例集中管理。

  4. 没有任何性能影响。

  5. 支持在线切换。

  6. 跨存储引擎,支持任何引擎。

官方介绍:https://code.google.com/p/mysql-master-ha

首先是我们DBA对其中一台服务器经过初始化设置和优化,比如按数据库的最优策略调整内核参数,分区和挂在磁盘,预装pt-tool MHA Node Xtrbackup Innotop oak-tool等数据库常用的管理软件,然后交付给运维同学进行打包镜像,之后所有交付给DBA的服务器都是按此镜像进行部署。这样一来,我们的OS服务器就非常标准化了,同时也预装了我们常用的管理工具。

3.3.6.从库初始化同步数据
mysql> change master to master_host='192.168.217.130',master_port=3389,master_user='replica',master_password='mycatDBA',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> start slave;
Query OK, 0 rows affected (0.03 sec)


mysql> show slave status G
*************************** 1. row ***************************
...... 省略 ......
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
...... 省略 ......

MHA组件介绍

MHA软件由两部分组成,Manager工具包和Node工具包,具体的说明如下。

Manager工具包主要包括以下几个工具:

(1)masterha_check_ssh    #检查MHA的SSH配置状况;

(2)masterha_check_repl    #检查MySQL复制状况;

(3)masterha_manger    #启动MHA;

(4)masterha_check_status  #检测当前MHA运行状态;

(5)masterha_master_monitor  #检测master是否宕机;

(6)masterha_master_switch    #控制故障转移(自动或者手动);

(7)masterha_conf_host    #添加或删除配置的server信息;

Node工具包(这些工具通常由MHA Manager的脚本触发,无需人为操作)主要包括以下几个工具:

(1)save_binary_logs      #保存和复制master的二进制日志;

(2)apply_diff_relay_logs  #识别差异的中继日志事件并将其差异的事件应用于其他的slave;

(3)purge_relay_logs      #清除中继日志(不会阻塞SQL线程);

注意:为了尽可能的减少主库硬件损坏宕机造成的数据丢失,因此在配置MHA的同时建议配置成MySQL半同步复制。关于半同步复制原理各位自己进行查阅(不是必须)。

转自:

我们的数据库也有自己的部署标准,比如配置文件标准化,除了部分可调参数是变量,其他参数全部使用标准化模板;另外像MySQL的安装目录、数据目录、二进制日志目录、临时文件目录都有统一的标准,根据不同的实例端口来区分。

3.1.1.软件参考文档

参考文档:
MHA原理:https://code.google.com/p/mysql-master-ha/wiki/HowMHAWorks
MHA原理PPT:http://www.slideshare.net/matsunobu/automated-master-failover
Linux配置代理方法:http://blog.csdn.net/bojie5744/article/details/42148719

软件下载:
Centos Base Yum Repository: http://mirrors.163.com/.help/CentOS6-Base-163.repo
epel(RHEL 6)Yum Repository:http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
MySQL5.7 Yum Repository:https://dev.mysql.com/get/mysql57-community-release-el6-11.noarch.rpm
mysql-master-ha(mgr):https://github.com/linyue515/mysql-master-ha/raw/master/mha4mysql-manager-0.57-0.el7.noarch.rpm
mysql-master-ha(node):https://github.com/linyue515/mysql-master-ha/raw/master/mha4mysql-node-0.57-0.el7.noarch.rpm

同时系统将提供Restful API用于内部数据更新,提供HTTP API用于外部系统对接,例如和CMDB、发布平台等平时实现数据共享和任务对接,提供消息通知功能用于发送各类报警和服务类的通知功能,提供任务上报功能用于各工作模块和WEB层的信息对接。

图片来自网络

既然作为平台,那么WEB管理界面、任务调度、API服务几个核心部分是不可以少的。下面展示一个建设初期的一个基础架构:

3.4.部署MHA软件

mysql-error.log

3.2.6.启动mysql实例
# mysqld_safe --defaults-file=/etc/mysql/my3389.cnf &
# cat /data1/db3389/error.log | grep temp
# mysql -S /data1/db3389/my3389.sock -p'z&Di4b_oSM*-'
mysql> set password=''; #重置密码为空

最后讲一点题外话,经常看到一些文章在讲数据库自动化、未来AI智能化,预测将来DBA可能会失业。这个观点我是二分之一认同的:随着很多公司的自动化越来越完善,可能需要的DBA会越来越少,但我认为DBA这个岗位在任何时候都不会被淘汰。

3.3.1.主库创建复制用户
mysql> grant replication slave, replication client on *.* to replica@'192.168.217.%' identified by 'mycatDBA';

通过DB平台和公司其他部门的平台相互打通,减少了很多人为操作环节,实现了数据库管理闭环。

3.3.3.主库备份数据库
# mysqldump -S /data1/db3389/my3389.sock --single-transaction --master-data=2 --opt -A | gzip >  /data1/tmp/full_3389.tar.gz

三、关于模块化设计构建

1.MHA简介

MHA是什么?
MHA是由日本Mysql yoshinorim专家(原就职于DeNA现就职于FaceBook)用Perl写的一套Mysql故障切换方案,来保障数据库的高可用性,它的功能是能在0-30s之内实现主Mysql故障转移(failover),MHA故障转移可以很好的帮我们解决从库数据的一致性问题,同时最大化挽回故障发生后数据的一致性。
官方网站:https://code.google.com/p/mysql-master-ha/

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在较大程度上保证数据的一致性,以达到真正意义上的高可用。

该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,较大程度的保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了的数据。使用MySQL 5.5的半同步复制,可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了的二进制日志,MHA可以将的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。

mysql-tmpdir

2.MHA原理

系统的核心是任务调度管理层,我们任务管理的界面如下所示,可以看到每个任务都有一个任务模块名称,并实时记录任务执行状态和执行日志:

3.2.2.创建配置文件目录
# mkdir /etc/mysql

/etc/my3307.cnf

3.1.背景介绍

binlog

3.2.5.初始化MySQL实例
# mysqld --defaults-file=/etc/mysql/my3389.cnf --initialize --user=mysql
# mysql_ssl_rsa_setup 

mysql-tmpdir

3.4.2.挂在VIP
  • master
# /sbin/ifconfig eth0:1 192.168.217.201 broadcast 192.168.217.255 netmask 255.255.255.0
# /sbin/arping -f -q -c 5 -w 5 -I eth0 -s 192.168.217.201 -U 192.168.217.2

然后我们监控上报的任务日志可以看到底层执行过程,大家可以看到任务会创建2个实例,然后配置了主从,最后配置了MHA,当然这里面还有一些元数据维护,备份和监控开关设置等等,其实在后台已经完成了。大概6分钟,完成了一个DBA半天的工作,并且保证了部署的数据库都是标准化的,不同DBA部署没有任何差异。

2.1.MHA工作原理

图片 4

image.png

当master出现故障时,通过对比slave之间I/O线程读取masterbinlog的位置,选取最接近的slave做为latestslave。 其它slave通过与latest slave对比生成差异中继日志。在latest slave上应用从master保存的binlog,同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。

在MHA实现Master故障切换过程中,MHA Node会试图访问故障的master(通过SSH),如果可以访问(不是硬件故障,比如InnoDB数据文件损坏等),会保存二进制文件,以最大程度保 证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。流程如下:

  • 从宕机崩溃的master保存二进制日志事件(binlog events)。
  • 识别含有最新更新的slave。
  • 应用差异的中继日志(relay log)到其它slave。
  • 应用从master保存的二进制日志事件(binlog events)。
  • 提升一个slave为新master并记录binlog file和position。
  • 使其它的slave连接新的master进行复制。
  • 完成切换manager主进程OFFLINE

binlog

3.4.8.启动BINLOG SERVER
# su - mysql
$ cd /data1/mha/binlog/3389;
$ mysqlbinlog -R --host=192.168.217.130 -P3389 --user=mha --password=mysqlDBA  --raw --stop-never 2171303389-bin.000003 &
$ ps -ef | grep mysqlbinlog | grep -v grep  # 验证binlog server进程是否存在
root       7008   6233  0 07:00 pts/0    00:00:00 mysqlbinlog -R --host=192.168.217.130 -P3389 --user=mha --password=x xxxxxx --raw --stop-never 2171303389-bin.000003
  • Level 1为底层支持模块:例如SSH操作模块、MySQL连接和操作模块、消息模块(短信,邮件,内部信息)、日志模块、外部接口模块(DNS变更,CDMD同步等)、元数据维护模块(meatdata)等。
  • Level 2为基础单元模块:比如安装MySQL节点、配置主从、配置MHA、创建数据库、DB授权等等,这些都是二级模块,基本就是完成某一个特定功能。注意Level 2里代码除了业务逻辑部分,其余只需要调用Level 1的模块即可。例如下面是一个安装MySQL实例的截图,属于二级模块:

1.2.背景和目标

在早期的MySQL架构中最主流就就是MySQL复制的主从结构,但伴随时间的推移以及数据的膨胀会出现一下几类问题。

  • 以前几十台DB服务器,人工登陆服务器就能维护好,也没有高可用,当master挂了,通知业务将IP切换到slave然后重启也能基本满足业务要求,但是业务迅速发展,实例数不断增加,复制集不断增加,数据库架构多样化,而这种人工维护方式显然大大增加了DBA工作量,而且效率低下、容易出错。

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

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

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

    1.数据一致性保证这个是最基本的同时也是前提,如果主备的数据的不一致,那么切换就无法进行,当然这里的一致性也是一个相对的,但是要做到最终一致性。
    2.故障快速切换,当master故障时这里可以是机器故障或者是实例故障,要确保业务能在最短时间切换到备用节点,使得业务受影响时间最短。这里也可以指业务例行维护操作,比如前面提到的无法使用在线进行DDL的DDL操作,很多分表批量的DDL操作,这些操作通过在线切换方式来滚动完成。
    3.简化日常维护,通过高可用平台来自动完成高可用的部署、维护、监控等任务,能够最大程度的解放DBA手动操作,提高日常运维效率。
    4.统一管理,当复制集很多的情况下,能够统一管理高可用实例信息、实例信息、监控信息、切换信息等。
    高可用的部署要对现有的数据库架构无影响,如果因为部署高可用,需要更改或者调整数据库架构则会导致成本增加。

  • 第一层为WEB控制层;
  • 第二层为任务管理层和数据采集层,用于任何调度管理和数据的交互处理;
  • 第三层为工作模块层,用于实现各功能的功能,比如安装实例、配置Replication、配置MHA、创建数据库、授权等等,这些都是由不同的底层模块来完成,通常由一系列脚本组成。
3.3.5.从库恢复数据库
# gunzip < /data1/tmp/full_3389.tar.gz | mysql -S /data1/db3389/my3389.sock

注意:恢复数据库前,从库最好reset master;,否则将出现一下错误:
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

在大家的共同努力下,MySQL以及Redis日常部署和维护工作都实现了任务调度化管理。通常需要大家登录服务器的操作现在基本都在WEB界面端就完成了。一般除了需要登服务器定位问题和处理线上故障,基本就白屏化了数据库管理。

3.5.1.故障切换
  • 主库down或者主机down,然后测试切换是否成功。

/storage/fioa/mysql3308:

3.4.3.配置SSH互信

在现网环境中几乎都是禁止root远程登陆服务器得,所以ssh免密码登陆要在mysql用户下进行配置,这是处于安全角度考虑出发。

  • master:
# su - mysql
$ ssh-keygen -t rsa
$ rm -rf ~/.ssh/*
  • slave:
# su - mysql
$ ssh-keygen -t rsa
$ rm -rf ~/.ssh/*
  • manager:
# su - mysql
$ ssh-keygen -t rsa
$ cd ~/.ssh
$ mv id_rsa.pub authorized_keys
$ scp * 192.168.217.130:~/.ssh/
$ scp * 192.168.217.131:~/.ssh/
$ #测试ssh
$ ssh 192.168.217.130 date 
Wed Nov 22 05:48:54 PST 2017
$ ssh 192.168.217.131 date 
Wed Nov 22 05:47:58 PST 2017

两年多的时间里,我们DBA Team快速完成了数据库自动化、白屏化、闭环化、服务化的建设。完成了JKDB数据库自动化平台(含元数据管理、自动化部署调度系统、监控系统、备份系统、高可用和在线切换、容量趋势分析规划、校验中心等)、数据库自助查询平台、权限申请和审批平台、自助变更执行平台、流程引擎、工单系统、敏感信息探测系统等等。

2.3.当前高可用方案

  • keepalived mysql复制
    该结构与MHA类似,但keepalived的优势在于无状态组件的故障切换,常用于web前端的故障转移,应用于数据库场景中,最致命的问题就是脑裂以后数据乱写的风险,为企业带来巨大困扰。

  • MySQL Cluster
    MySQL Cluster真正实现了高可用,但是使用的是NDB存储引擎,并且SQL节点有单点故障问题。

  • 半同步复制(5.5 )
    半同步复制大大减少了“binlog events只存在故障master上”的问题。在提交时,保证至少一个slave(并不是所有的)接收到binlog,因此一些slave可能没有接收到binlog。

  • PXC
    PXC实现了服务高可用,数据同步时是并发复制。但是仅支持InnoDB引擎,所有的表都要有主键。锁冲突、死锁问题相对较多等等问题。

有了上述自动化任务调度平台和设计规范作为基础,我们DBA基本都很快参与进行了进行模块开发。模块开发的好处就是大家很容易上手开发,甚至之前有不会Python的同学,在简单学习了Python之后也能照猫画虎很快完成一个模块。

3.1.3.安装系统要求
  • 涉及所有服务器关闭iptables、NetworkManager服务、selinux安全配置
# /etc/init.d/NetworkManager stop
# chkconfig NetworkManager off
# /etc/init.d/iptables stop
# chkconfig iptables off

/etc/selinux/config 改成disable

data

文章大纲

  1. MHA简介
    1.1. mha组件介绍
    1.2. 背景和目标
  2. MHA原理
    2.1. MHA工作原理
    2.2. MHA工具介绍
    2.3. 当前高可用方案
    2.4. MHA的优势
  3. MHA最佳实践
    3.1. 背景介绍
    3.2. 安装MySQL实例
    3.3. 部署MySQL复制
    3.4. 部署MHA软件
    3.5. 故障自动切换与在线切换

版权声明:本文由金沙国际登录网址发布于科技传媒,转载请注明出处:MySQL基于MHA高可用理论篇,白屏化背后