三、关于模块化设计构建

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

/storage/fioa/mysql3308:

1.1.mha组件介绍

  • MHA Manager
    运行一些工具,比如masterha_manager工具实现自动监控MySQL
    Master和实现master故障切换,其它工具实现手动实现master故障切换、在线mater转移、连接检查等等。一个Manager可以管理多
    个master-slave集群

  • MHA Node
    部署在所有运行MySQL的服务器上,无论是master还是slave。主要作用有三个。
    1.保存二进制日志
    如果能够访问故障master,会拷贝master的二进制日志
    2.应用差异中继日志
    从拥有最新数据的slave上生成差异中继日志,然后应用差异日志。
    3.清除中继日志
    在不停止SQL线程的情况下删除中继日志

其一是标准化,标准化是自动化的重要前提。那个时候,我们这边标准化是做得比较好的,从OS的标准化到DB层的标准化都有着统一的标准。比如OS的操作系统版本、文件系统格式、磁盘挂载点、预装软件、内核参数等等,我们所有MySQL服务器基本都是一致的。

3.2.4.创建授权目录
# mkdir -p /data1/db3389
# mkdir -p /data1/tmp
# chown -R mysql:mysql /data1/db3389
# chown -R mysql:mysql /data1/tmp

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

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
...... 省略 ......

3.2.安装MySQL实例

  • Level
    1为底层支持模块:
    例如SSH操作模块、MySQL连接和操作模块、消息模块(短信,邮件,内部信息)、日志模块、外部接口模块(DNS变更,CDMD同步等)、元数据维护模块(meatdata)等。
  • Level
    2为基础单元模块:
    比如安装MySQL节点、配置主从、配置MHA、创建数据库、DB授权等等,这些都是二级模块,基本就是完成某一个特定功能。注意Level
    2里代码除了业务逻辑部分,其余只需要调用Level
    1的模块即可。例如下面是一个安装MySQL实例的截图,属于二级模块:
3.4.5.创建MHA配置文件
  • 创建配置文件目录

# mkdir /etc/mha
  • 创建MHA配置文件

# cat app3389.cnf 
[server default]
user=mha
password=mysqlDBA
manager_workdir=/data1/mha/masterha/app3389
manager_log=/data1/mha/masterha/app3389/app3389.log
remote_workdir=/data1/mha/masterha/app3389
ssh_user=mysql
repl_user=replica    
repl_password=mycatDBA
ping_interval=3         

secondary_check_script="masterha_secondary_check -s 192.168.1.122 -s 192.168.1.122"
master_ip_failover_script="/etc/mha/master_ip_failover.sh 192.168.1.201 1"
master_ip_online_change_script="/etc/mha/master_ip_online_change.sh 192.168.1.201 1"
shutdown_script="/etc/mha/power_manager"
#report_script="/etc/mha/end_report"

[server1]
hostname=192.168.1.120
port=3389
master_binlog_dir=/data1/db3389
candidate_master=1   
master_pid_file=/data1/db3389/mysql.pid               

[server2]
hostname=192.168.1.121
port=3389
master_binlog_dir=/data1/db3389
candidate_master=1
master_pid_file=/data1/db3389/mysql.pid    

[binlog1]
hostname=192.168.1.122
master_binlog_dir=/data1/mha/binlog/3389
no_master=1
ignore_fail=1

图片 1

2.1.MHA工作原理

图片 2

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

mysql-error.log

3.4.7.创建MHA、BINLOG工作目录
# mkdir -p /data1/mha/masterha/app3389
# mkdir -p /data1/mha/binlog/3389
# chown -R mysql:mysql /data1/mha/binlog/3389

图片 3

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

mysql-error.log

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.3.当前高可用方案

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

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

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

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

mysql-tmpdir

3.2.1.安装mysql数据库
  • 创建mysql用户

# useradd mysql
# passwd mysql
  • 安装软件

# yum -y install mysql-community-server.x86_64

在上面我们简单介绍了系统的基础架构,里面提到了底层任务模块,比如安装实例、创建主从模块等等,那么这些模块底层如何优雅地设计呢?

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

图片 4

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=''; #重置密码为空

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

2.MHA原理

mysql-error.log

图片来自网络

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

图片 5

当然MySQL严格要做到标准化,在未做到自动化部署之前,是比较困难的,困难的不是部署技术,而是规则意识。通常一个公司都有好多个DBA共同管理数据库,由于之前的工作习惯大家喜欢按照自己的方式来部署数据库,或者没有标准部署规则、有规则但是没有严格遵守,都是无法做到标准化的。我们是从一开始就做了标准化规则和自动化部署脚本,所以我们目前线上所有数据库的部署都是标准化的,为后续自动化平台建设打下了非常好的基础。

文章大纲

  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. 故障自动切换与在线切换

/etc/my3308.cnf

3.4.部署MHA软件

上面这幅图可以很好的解释底层的三级模块调用流程:

3.1.背景介绍

责任编辑:

文/Bruce.Liu1

自动化创建的实例按照端口进行标准化部署,如下所示,某台服务器安装了3306、3307、3308三个端口,则部署目录如下所示:

3.4.4.配置mysql用户sudo权限
  • 添加普通用户登陆tty终端权限

# vim /etc/sudoers

#将以下的参数注释,意思就是sudo默认需要tty终端。注释掉就可以在后台执行了。
#Defaults    requiretty
  • 开放普通用户执行sudo命令权限

# cd /etc/sudoers.d/
# vim mysql

User_Alias  MYSQL_USERS = ALL
Runas_Alias MYSQL_RUNAS = root
Cmnd_Alias  MYSQL_CMNDS = ALL
MYSQL_USERS ALL = (MYSQL_RUNAS) NOPASSWD: MYSQL_CMNDS

这样部署的数据库达到了标准化的水平,所以我们DBA只要知道IP和端口,就可以很容易地知道这个实例的所有信息,无疑是自动化的良好基石。

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

关于数据库标准化构建

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

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

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

图片 6

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.

业务与技术往往是共同前进的,2016年,我加入平安好医生,在业务快速发展的同时,我们的数据库自动化平台也得到了快速的建设和发展。

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

图片 7

3.4.6.上传MHA切换脚本

master_ip_failover.sh
master_ip_online_change.sh
power_manager

注意:脚本内容中要修改网卡名字

my $vip  = shift;
my $interface = 'eth1';
my $key = shift;
  • 上传故障切换脚本并授权

# chmod 755 master_ip_*
# chmod 755 power_manager

mysql-tmpdir

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

我们知道运维同学常常忙于很多琐碎的事情,效率优先,也习惯于脚本化开发,可能分分钟就写一个脚本实现某个功能。但是在平台建设中,这种方式是不可取的。如果代码没有规范的思想指导,当多人协同开发的过程中,很难进行项目的管理和跟进。

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服务器上,因此可以保证所有节点的数据一致性。

  • 第一层为WEB控制层;
  • 第二层为任务管理层和数据采集层,用于任何调度管理和数据的交互处理;
  • 第三层为工作模块层,用于实现各功能的功能,比如安装实例、配置Replication、配置MHA、创建数据库、授权等等,这些都是由不同的底层模块来完成,通常由一系列脚本组成。
3.4.1.安装软件
  • epel yum源安装方式

# yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
# #根据MHA角色安装对应的软件包即可
# yum -y --nogpgcheck install mha4mysql-node-0.57-0.el7.noarch.rpm
# yum -y install --nogpgcheck mha4mysql-manager-0.57-0.el7.noarch.rpm
  • 本地安装方式

# yum -y --nogpgcheck install perl-DBD-MySQL*
# yum -y --nogpgcheck install perl-Config-Tiny*
# yum -y --nogpgcheck install perl-Parallel-ForkManager*
# yum -y --nogpgcheck install  perl-MailTools*
# yum -y --nogpgcheck install perl-Email-Date-Format*
# yum -y --nogpgcheck install perl-Mail-Sender*
# yum -y --nogpgcheck install perl-MIME-Types*
# yum -y --nogpgcheck install perl-MIME-Lite*
# yum -y --nogpgcheck install perl-Mail-Sendmail*
# yum -y --nogpgcheck install perl-Log-Dispatch*
# #根据MHA角色安装对应的软件包即可 
# yum -y --nogpgcheck install mha4mysql-node-0.57-0.el7.noarch.rpm
# yum -y install --nogpgcheck mha4mysql-manager-0.57-0.el7.noarch.rpm

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

3.2.3.创建配置文件
[mysqld]
# GENERAL #
user                           = mysql
port                           = 3389
default_storage_engine         = InnoDB
socket                         = /data1/db3389/my3389.sock
pid_file                       = /data1/db3389/mysql.pid
#read-only =0
tmpdir                  = /data1/tmp
#key_buffer_size                = 128M
max_allowed_packet             = 32M
max_connect_errors             = 1000000
datadir          = /data1/db3389/
log_bin = 2171303389-bin
relay-log=  2171303389-relay-bin
expire_logs_days               = 7
#sync_binlog                    = 0
tmp_table_size                 = 32M
max_heap_table_size            = 32M
max_connections                = 5000
thread_cache_size              = 512
table_definition_cache         = 4096
table_open_cache               = 4096
wait_timeout            = 28800
interactive_timeout     = 28800
transaction-isolation = READ-COMMITTED
binlog-format=row
character-set-server=utf8
skip-name-resolve
back_log=1024
explicit_defaults_for_timestamp=true
server_id=2171303389

# INNODB #
innodb_flush_method            = O_DIRECT
#innodb_data_home_dir = /data1/db3389
innodb_data_file_path = ibdata1:100M:autoextend
#redo log
#innodb_log_group_home_dir=./
innodb_log_files_in_group      = 3
innodb_log_file_size           = 128M
#innodb performance
innodb_flush_log_at_trx_commit = 0
innodb_file_per_table          = 1
innodb_buffer_pool_instances   = 8
innodb_io_capacity             = 2000
innodb_lock_wait_timeout       = 30
binlog_error_action = ABORT_SERVER
innodb_buffer_pool_size        = 128M
innodb_max_dirty_pages_pct=90
innodb_file_format=Barracuda
innodb_support_xa=0
innodb_buffer_pool_dump_at_shutdown = 1
innodb_buffer_pool_load_at_startup = 1
#innodb undo log
innodb_undo_tablespaces=4
innodb_undo_logs=2048
innodb_purge_rseg_truncate_frequency=512
innodb_max_undo_log_size=2G
innodb_undo_log_truncate=1

log_error                      = error.log
#log_queries_not_using_indexes = 1
slow_query_log                 = 1
slow_query_log_file            = slow-queries.log
long_query_time=2
gtid_mode=ON
enforce-gtid-consistency
log-slave-updates
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync_master_info = 10000
slave_sql_verify_checksum=1
skip-slave-start
init-connect='SET NAMES utf8'
character-set-server=utf8
skip-character-set-client-handshake
bind-address=0.0.0.0
skip-external-locking
slave-parallel-workers=6

[mysql5.6]
myisam_recover                 = FORCE,BACKUP

/etc/my3307.cnf

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.统一管理,当复制集很多的情况下,能够统一管理高可用实例信息、实例信息、监控信息、切换信息等。
    高可用的部署要对现有的数据库架构无影响,如果因为部署高可用,需要更改或者调整数据库架构则会导致成本增加。

数据库安装路径:

2.2.MHA工具介绍

1.Manager工具:

  • masterha_check_ssh : 检查MHA的SSH配置。
  • masterha_check_repl : 检查MySQL复制。
  • masterha_manager : 启动MHA。
  • masterha_check_status : 检测当前MHA运行状态。
  • masterha_master_monitor : 监测master是否宕机。
  • masterha_master_switch : 控制故障转移(自动或手动)。
  • masterha_conf_host : 添加或删除配置的server信息。

2. Node工具

  • save_binary_logs : 保存和复制master的二进制日志。
  • apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。
  • filter_mysqlbinlog :
    去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。
  • purge_relay_logs : 清除中继日志(不会阻塞SQL线程)。
    注意:Node这些工具通常由MHA Manager的脚本触发,无需人手操作。

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

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

/etc/my3306.cnf

2.4.MHA的优势

  • 障切换快

    主从复制集群中,只要从库在复制上没有延迟,MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障,可以选择在7-10秒关闭
    master以避免出现裂脑,几秒钟内,将差异中继日志(relay
    log)应用到新的master上,因此总的宕机时间通常为10-30秒。恢复新的master后,MHA并行的恢复其余的slave。即使在有数万台
    slave,也不会影响master的恢复时间。
    DeNA在超过150个MySQL(主要5.0/5.1版本)主从环境下使用了MHA。当mater故障后,MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中,4秒内完成故障切换是不可能的。

  • master故障不会导致数据不一致
    当 目前的master出现故障是,MHA自动识别slave之间中继日志(relay
    log)的不同,并应用到所有的slave中。这样所有的salve能够保持同步,只要所有的slave处于存活状态。和Semi-
    Synchronous Replication一起使用,(几乎)可以保证没有数据丢失。

  • 需修改当前的MySQL设置
    MHA的设计的重要原则之一就是尽可能地简单易用。MHA工作在传统的MySQL版本5.0和之后版本的主从复制环境中。和其它高可用解决方法比,MHA并不需要改变MySQL的部署环境。MHA适用于异步和半同步的主从复制。
    启动/停止/升级/降级/安装/卸载MHA不需要改变(包扩启动/停止)MySQL复制。当需要升级MHA到新的版本,不需要停止MySQL,仅仅替换到新版本的MHA,然后重启MHA Manager就好了。
    MHA运行在MySQL
    5.0开始的原生版本上。一些其它的MySQL高可用解决方案需要特定的版本(比如MySQL集群、带全局事务ID的MySQL等等),但并不仅仅为了
    master的高可用才迁移应用的。在大多数情况下,已经部署了比较旧MySQL应用,并且不想仅仅为了实现Master的高可用,花太多的时间迁移到不
    同的存储引擎或更新的前沿发行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上,所以并不需要迁移。

  • 无需增加大量的服务器
    MHA由MHA Manager和MHA Node组成。MHA
    Node运行在需要故障切换/恢复的MySQL服务器上,因此并不需要额外增加服务器。MHA
    Manager运行在特定的服务器上,因此需要增加一台(实现高可用需要2台),但是MHA
    Manager可以监控大量(甚至上百台)单独的master,因此,并不需要增加大量的服务器。即使在一台slave上运行MHA
    Manager也是可以的。综上,实现MHA并没用额外增加大量的服务。

  • 无性能下降
    MHA适用与异步或半同步的MySQL复制。监控master时,MHA仅仅是每隔几秒(默认是3秒)发送一个ping包,并不发送重查询。可以得到像原生MySQL复制一样快的性能。

  • 适用于任何存储引擎
    MHA可以运行在只要MySQL复制运行的存储引擎上,并不仅限制于InnoDB,即使在不易迁移的传统的MyISAM引擎环境,一样可以使用MHA。

例如,我们在管理机使用如下命令,则会在对应的IP服务器上创建一个innodb_buffer_pool等于10GB的数据库实例,端口为3306,挂载设备为fioa,版本为MySQL-5.6.28-OS7-x86_64,数据库编码为utf8:

3.MHA最佳实践

图片 8

图片来自网络

  • Level 3则为服务模块:真正经常使用的模块,都是调用Level
    2模块来进行封装的。例如在一般业务方使用数据库中,DBA至少需要安装2个实例,配置个主从复制,也需要配置MHA,当然备份和监控配置也不能少。这些工作一个DBA来完成通常大半天时间过去了。那么如果需要部署10套呢?会花费更多的时间。所以这种情况下就需要一键部署,一键通通搞定。说到这里,还有一个问题——大家大概也注意到了安装实例、创建数据库等这些单一模块在Level
    2模块都有,那么Level 3干嘛呢?其实就是调用Level
    2就可以了。如下是一键部署页面截图,DBA填写好提交任务即可,剩下的时候就可以处理其他工作了:
3.3.3.主库备份数据库
# mysqldump -S /data1/db3389/my3389.sock --single-transaction --master-data=2 --opt -A | gzip >  /data1/tmp/full_3389.tar.gz

相关文章