MySQL在互联网应用中已经遍地开花，但是在银行系统中，还在生根发芽的阶段。本文记录的是根据某生产系统实际需求，对数据库高可用方案从需求、各高可用技术特点对比、实施、测试等过程进行整理，完善Mysql高可用方案，同时为后续开展分布式数据库相关测试做相应准备。
存储复制技术： 传统IOE架构下，常用高可用方案，靠存储底层复制技术实现数据的一致性，优点数据安全性有保障，限制在于是依赖存储硬件，实施成本较高。
keepalived+双主复制： 两台MySQL互为主从关系，即双主模式，通过Keepalived配置虚拟IP，实现当其中的一台数据库故障时，自动切换VIP到另外一台MySQL数据库，备机快速接管业务来保证数据库的高可用。
MHA： MHA部署在每台mysql服务器上，定时探测集群中的master节点，当master出现故障时，它可以自动将最新的slave提升为新的master，然后将所有其他的slave重新指向新的master，优点在最大程度保证数据的一致性的前提下实现快速切换，最少需要3台服务器，存在数据丢失的可能性。
PXC： Percona eXtra Cluster是Percona基于galera cluster封装的集群方案。不同于普通多主复制，PXC保障强一致性和实时同步，故障切换更快。但是也需要3个节点，配置相对复杂，对性能也稍有影响。
除了上述方案外，还有MMM、Heartbeat+DRBD等高可用方案，此处不做详细介绍。
综合评估下，本次实施采用了 keepalived+mysql双主实现数据库同城双机房的高可用。MySQL版本为： 5.7.21。 *** 作系统：Red Hat Enterprise Linux Server 7.3。
配置过程如下：
Mysql-master1: IP地址1 --以下简称master1
Mysql-master2: IP地址2 --以下简称master2
Mysql-vip : VIP地址 --应用连接使用
Mysql复制相关概念描述：
1、 Mysql主从复制图示：
2、 Mysql主从复制过程描述：
（1）master记录二进制日志：在每个事务更新数据完成之前，master在二进制日志记录这些改变。MySQL将事务写入二进制日志。在事务写入二进制日志完成后，master通知存储引擎提交事务。
（2）slave将master的binarylog拷贝到自己的中继日志：首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事务，如果已经同步了master，它会睡眠并等待master产生新的事件。I/O线程将这些事务写入中继日志。
（3）SQL slave thread处理该过程的最后一步：SQL线程从中继日志读取事务，并重放其中的事务而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。
主主同步就是两台机器互为主的关系，在任何一台机器上写入都会同步至备端。
为了便于后续数据库服务器的扩展，且在整个复制环境中能够自动地切换，降低运维成本，引入了当前主流的基于Mysql GTID的复制特性，工作原理及优缺点简介如下。
3、 GTID工作原理简介：
（1） master更新数据时，会在事务前产生GTID，一同记录到Binlog日志中。
（2） slave的I/O线程将变更的binlog写入到本地的relay log中。
（3） slave的sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
（4） 如果有记录说明该GTID的事务已经执行，slave会忽略。
（5） 如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
（6） 在解析的过程中会判断是否有主键，如果有就用索引，如果没有就用全部扫描。
4、 GTID优点：
（1） 一个事务对应一个唯一的ID，一个GTID在一个服务器上 只会执行一次。（2） GTID是用来替代传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。
（3） 减少手工干预和降低服务故障时间，当主机宕机之后会通过软件从众多的备机中提升一台备机为新的master。
5、 GTID也存在一些限制：
（1） 不支持非事务引擎。
（2） 不支持create table … select 语句复制(主库直接报错)。
（3） 不允许一个sql同时更新一个事务引擎表和非事务引擎表。
（4） 在一个复制组中，必须要求统一开启GTID或者是统一关闭GTID。
（5） 开启GTID需要重启(5.7版本除外)。
（6） 开启GTID后，就不再使用原理的传统复制方式。
（7） 不支持create temporary table 和 drop temporary table语句。
（8） 不支持sql_slave_skip_counter。
前置条件：
主备两个节点使用行内统一的安装部署脚本安装mysql5.7.21介质(略)
Master1端创建应用的数据库(略)
1、 修改MySQL配置文件
参考相关配置规范，分别设置master1、master2的my.cnf文件，
其中server-id参数设置为不同值
由于后续keepalived会挂起VIP，应用通过VIP连接数据库，为了避免应用程序无法通过VIP访问，需将两个节点的bind-address参数注释掉；
2、 设置master1端自动半同步模式
Mysql的同步模式主要有如下3种：
a. 主从同步复制：数据完整性好，但是性能消耗略高；
b. 主从异步复制：性能消耗低，但容易出现不一致；
c. 主从半自动复制：介于上述两种之间，既保持了数据的完整性，又提高了性能；
基于上述特性，建议采用半自动同步模式，由于后续要配置为双主模式，因此任一节点其角色既为master又为slave，因此相关的master/slave插件要同时配置，过程如下。
（1） 首先查看库是否支持动态加载(默认都支持)
（2） 主从库上分别安装插件
作为主库，安装插件semisync_master.so
作为从库，安装插件semisync_slave.so
（3） 安装完成后，从plugin表中能够看到刚刚安装的插件
（4） 分别打开主从库半同步复制
同时添加到各自的my.cnf中，在后续数据库实例重启时自动加载该配置。
此时查看状态还没有启动
（5） 两个节点分别启动IO进程
（6） 查看半同步状态
3、 将master1设为master2的主服务器
（1）在master1主机上创建授权账户，允许在master2主机上连接
（2）将主库master1数据导出
（3）将master.sql传输到master2上并导入
（4）在master2端将master1设置为自己的主库，并开启slave功能
在master2上查看slave状态
至此master1到master2的主从复制关系已经建立完成。
4、 将master2设为master1的主服务器
在master1上执行
在master1上查看slave状态
1、keepalived相关概念说明：
keepalived是集群管理中保证集群高可用的一个软件解决方案，其功能类似于heartbeat，用来防止单点故障
keepalived是以VRRP协议为实现基础的，VRRP全称VirtualRouter Redundancy Protocol，即虚拟路由冗余协议。
虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip，master会发组播（组播地址为224.0.0.18），当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，这样的话就可以保证路由器的高可用了。
keepalived主要有三个模块，分别是core 、check和vrrp。core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。check负责 健康 检查，包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。同时为了避免出现脑裂，应关闭防火墙或者开启防火墙但允许接收VRRP协议。
2、keepalived的安装配置
（1）配置本地yum源，在master1和master2两台服务器上安装keepalived的相关依赖包Kernel-devel/openssl-devel/popt-devl等
配置指向rhel-7.5.iso的yum本地源，步骤略
注意：如不知道keepalived需要哪些依赖包，可到下载后的源码解压目录下查看INSTALL 文件内容，安装需要的依赖包，源码安装任何一个软件都要养成查看源码包文档的习惯，比如INSTALL，README,doc等文档，可以获得很多有用的信息。
（2）在两台mysql上解压缩并编译安装keepalived
（3）master1、master2上分别配置keepalived.conf
注意上图红色字体中两个节点配置相同处及差异。
说明：keepalived只有一个配置文件keepalived.conf，里面主要包括以下几个配置区域：
· global_defs：主要是配置故障发生时的通知对象以及机器标识。
· vrrp_instance：用来定义对外提供服务的VIP区域及其相关属性。
· virtual_server：虚拟服务器定义
（4）同时两个节点上都需要添加检测脚本
作用：是当mysql停止工作时自动关闭本机的keeplived服务，从而实现将故障主机踢出热备组，因每台机器上keepalived只添加了本机为realserver，所以当mysqld正常启动后，我们还需要手动启动keepalived服务。
（5）分别启动两个节点的keepalived服务
检查两个节点keepalived启动进程
检查两个节点的vip挂载情况
（6）主备机故障切换测试
停止master2的mysql服务，看keepalived 健康 检查程序是否会触发脚本，自动进行故障切换，步骤略
查看master1节点的VIP挂载情况，验证是否实现了自动切换，步骤略
说明在master2服务器的mysql服务发生故障时，触发了脚本，自动完成了切换。
（7）现在我们把master2的mysql服务开起来，并且keepalived的服务也需要启动。
即便master2的mysql服务和keepalived服务都重新开启了，master1仍然是主master了，master2未对主master的权利进行抢夺，说明设置的nopreempt参数生效了，为了保证群集的稳定性，生产环境不允许抢占配置，只有当master1的mysql服务坏掉的时候，master2才会再次成为主master，否则它永远只能当master1的备份。（注：nopreempt一般是在优先级高的mysql上设置）
Sysbench是一个模块化的、跨平台、多线程基准测试工具，可用于评估数据库负载情况，通过sysbench命令配置IP地址、端口号、用户名、密码连接到指定的数据库db1中，创建多个表，并快速插入指定条数的记录，观察主备库同步效率
(1) 下载开源工具sysbench-0.4.12.14.tar.gz，放置在相应目录下并解压
(2) 使用iso配置本地yum源并安装Sysbench如下的依赖包(步骤略)：autoconf/automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc
(3) 编译sysbench
编辑配置文件/etc/ld.so.conf中添加mysql lib目录/mysql/app/5.7.21/lib，并执行命令ldconfig生效
(4) 执行sysbench压测
使用sysbench工具向主节点的db1数据库中创建5张表，并且每张表分别插入10万条记录
同时观察备机同步效率
几个重要的参数说明：
B、半自动同步模式、异步模式切换测试
(1) 检查主备同步状态，及同步参数设置
rpl_semi_sync_master_enabled参数表示启用半同步模式；
rpl_semi_sync_master_timeout参数单位为毫秒，表示主库事务等待从库返回commit成功信息超过10秒就降为异步模式，不再等待从库，等探测到从库io线程恢复后，再返回为半自动同步；
rpl_semi_sync_master_wait_no_slave参数表示事务提交后需要等待从库返回确认信息；
(2) 将slave的io线程停止
(3) 使用sysbench向master写入少量的数据，本例创建一张表，并插入10条记录，命令包装在1.sh测试脚本中
通过记录的时间戳发现，master在等待了slave10秒无响应，自动切换为异步模式，将数据写入本地。
(4) Slave启动io线程，数据自动追平
至此MySQL主主复制配置完成，运行在半自动同步模式，通过keepalived实现Mysql的HA高可用。
上线后应符合统一的标准监控策略，添加备份协议对数据进行周期备份并保存到带库中，以及定期的数据恢复测试。
由于是靠keepalived实现的高可用，还应将如下资源添加到监控管理平台：
1、 对每台数据库主机的3个keepalived进程进行监控；
2、 对主备节点的io线程、sql线程工作状态进行监控；
参考： https://www.jianshu.com/p/5e0062f6cf62
图中是两组分片，红色我们称为shard1，蓝色我们称为shard2
51 52是服务器
两个3307互为主从(双主)，3309是本地3307的从库
说明：没有明确说明是只在某一个节点上做的，就是两个节点都做
两台虚拟机 db01 db02
每台创建四个mysql实例：3307 3308 3309 3310
mysql软件我们之前已完成二进制安装，直接初始化即可
我们server-id规划为：db01上是7/8/9/10,db02上是17/18/19/20
"箭头指向谁是主库"
10.0.0.51:3307<-----> 10.0.0.52:3307
10.0.0.51:3309------> 10.0.0.51:3307
10.0.0.52:3309------> 10.0.0.52:3307
两个分片，每个分片四个mysql节点
shard1：
Master：10.0.0.51:3307
slave1：10.0.0.51:3309
Standby Master：10.0.0.52:3307
slave2：10.0.0.52:3309
shard2：
Master：10.0.0.52:3308
slave1：10.0.0.52:3310
Standby Master：10.0.0.51:3308
slave2：10.0.0.51:3310
shard1
10.0.0.51:3307 <----->10.0.0.52:3307
db02
db01
db02
10.0.0.51:3309 ------>10.0.0.51:3307
db01
10.0.0.52:3309 ------>10.0.0.52:3307
db02
shard2
10.0.0.52:3308 <----->10.0.0.51:3308
db01
db02
db01
10.0.0.52:3310 ----->10.0.0.52:3308
db02
10.0.0.51:3310 ----->10.0.0.51:3308
db01
这个复制用户在谁上建都行
注：如果中间出现错误，在每个节点进行执行以下命令
常见方案：
360 Atlas-Sharding 360
Alibaba cobar 阿里
Mycat 开源
TDDL 淘宝
Heisenberg 百度
Oceanus 58同城
Vitess 谷歌
OneProxy
DRDS 阿里云
我们装的是openjdk，不是官方的那个
Mycat-server-xxxxx.linux.tar.gz
http://dl.mycat.io/
配置环境变量
我们mycat的命令也是在bin目录下
启动
8066就是对外提供服务的端口，9066是管理端口
连接mycat：
默认123456
db01:
我们一般先把原schema.xml备份，然后自己新写一个：
xml和html看起来差不多，xml是从下往上调用的
前三行我们不用看，直接从第四行schema开始看起：
定义了schema，然后以/schema结尾
为什么要用逻辑库？
业务透明化
此配置文件就是实现读写分离的配置
重启mycat
读写分离测试
总结：
以上案例实现了1主1从的读写分离功能，写 *** 作落到主库，读 *** 作落到从库.如果主库宕机，从库不能在继续提供服务了。
我们推荐这种架构
一写三读，
不设置双写的原因是：性能没提升多少，反而引起主键冲突的情况
配置文件：
之后重启：mycat restart
真正的 writehost：负责写 *** 作的writehost
standby writeHost ：和readhost一样，只提供读服务
我们此处写了两个writehost，默认使用第一个
当写节点宕机后，后面跟的readhost也不提供服务，这时候standby的writehost就提供写服务，
后面跟的readhost提供读服务
测试：
读写分离测试
对db01 3307节点进行关闭和启动,测试读写 *** 作
结果应为另一台(52)的3307(17)是写，3309(19)是读
一旦7号节点恢复，此时因为7落后了，写节点仍是17
balance属性
负载均衡类型，目前的取值有3种：
writeType属性
负载均衡类型，目前的取值有2种：
switchType属性
-1 表示不自动切换
1 默认值，自动切换
2 基于MySQL主从同步的状态决定是否切换 ，心跳语句为 show slave status
datahost其他配置
<dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1">
maxCon="1000"：最大的并发连接数
minCon="10" ：mycat在启动之后，会在后端节点上自动开启的连接线程，长连接，好处是连接速度快，弊端是占内存
tempReadHostAvailable="1"
这个一主一从时（1个writehost，1个readhost时），可以开启这个参数，如果2个writehost，2个readhost时
<heartbeat>select user()</heartbeat> 监测心跳
其他参数sqlMaxLimit自动分页,必须在启用分表的情况下才生效
创建测试库和表:
我们重启mycat后连接到8066
发现跟一个库一样，实际上已经分到不同的物理硬件上了
分片：对一个"bigtable"，比如说t3表
热点数据表 核心表
(1)行数非常多，800w下坡
(2)访问非常频繁
分片的目的：
（1）将大数据量进行分布存储
（2）提供均衡的访问路由
分片策略：
范围 range 800w 1-400w 400w01-800w 不适用于业务访问不均匀的情况
取模 mod(取余数) 和节点的数量进行取模
枚举 按枚举的种类分，如移动项目按省份分
哈希 hash
时间 流水
优化关联查询（否则join的表在不同分片上，效率会比单库还要低）
全局表
ER分片
案例：移动统一：先拆出边缘业务，再按地域分片，但对应用来说是统一的
vim rule.xml
<tableRule name="auto-sharding-long">
<rule>
<columns>id</columns>
<algorithm>rang-long</algorithm>
</rule>
<function name="rang-long"
class="io.mycat.route.function.AutoPartitionByLong">
<property name="mapFile">autopartition-long.txt</property>
</function>
===================================
vim autopartition-long.txt
0-10=0
11-20=1
创建测试表：
mysql -S /data/3307/mysql.sock -e "use taobaocreate table t3 (id int not null primary key auto_increment,name varchar(20) not null)"
mysql -S /data/3308/mysql.sock -e "use taobaocreate table t3 (id int not null primary key auto_increment,name varchar(20) not null)"
测试：
重启mycat
mycat restart
mysql -uroot -p123456 -h 127.0.0.1 -P 8066
insert into t3(id,name) values(1,'a')
insert into t3(id,name) values(2,'b')
insert into t3(id,name) values(3,'c')
insert into t3(id,name) values(4,'d')
insert into t3(id,name) values(11,'aa')
insert into t3(id,name) values(12,'bb')
insert into t3(id,name) values(13,'cc')
insert into t3(id,name) values(14,'dd')
取余分片方式：分片键（一个列）与节点数量进行取余，得到余数，将数据写入对应节点
vim schema.xml
<table name="t4" dataNode="sh1,sh2" rule="mod-long" />
vim rule.xml
<property name="count">2</property>
准备测试环境
创建测试表：
mysql -S /data/3307/mysql.sock -e "use taobaocreate table t4 (id int not null primary key auto_increment,name varchar(20) not null)"
mysql -S /data/3308/mysql.sock -e "use taobaocreate table t4 (id int not null primary key auto_increment,name varchar(20) not null)"
重启mycat
mycat restart
测试：
mysql -uroot -p123456 -h10.0.0.52 -P8066
use TESTDB
insert into t4(id,name) values(1,'a')
insert into t4(id,name) values(2,'b')
insert into t4(id,name) values(3,'c')
insert into t4(id,name) values(4,'d')
分别登录后端节点查询数据
mysql -S /data/3307/mysql.sock
use taobao
select * from t4
mysql -S /data/3308/mysql.sock
use taobao
select * from t4
t5 表
id name telnum
1 bj 1212
2 sh 22222
3 bj 3333
4 sh 44444
5 bj 5555
sharding-by-intfile
vim schema.xml
<table name="t5" dataNode="sh1,sh2" rule="sharding-by-intfile" />
vim rule.xml
<tableRule name="sharding-by-intfile">
<rule><columns>name</columns>
<algorithm>hash-int</algorithm>
</rule>
</tableRule>
<function name="hash-int" class="org.opencloudb.route.function.PartitionByFileMap">
<property name="mapFile">partition-hash-int.txt</property>
<property name="type">1</property>
<property name="defaultNode">0</property>
</function>
partition-hash-int.txt 配置：
bj=0
sh=1
DEFAULT_NODE=1
columns 标识将要分片的表字段，algorithm 分片函数， 其中分片函数配置中，mapFile标识配置文件名称
准备测试环境
mysql -S /data/3307/mysql.sock -e "use taobaocreate table t5 (id int not null primary key auto_increment,name varchar(20) not null)"
mysql -S /data/3308/mysql.sock -e "use taobaocreate table t5 (id int not null primary key auto_increment,name varchar(20) not null)"
重启mycat
mycat restart
mysql -uroot -p123456 -h10.0.0.51 -P8066
use TESTDB
insert into t5(id,name) values(1,'bj')
insert into t5(id,name) values(2,'sh')
insert into t5(id,name) values(3,'bj')
insert into t5(id,name) values(4,'sh')
insert into t5(id,name) values(5,'tj')
a b c d
join
t
select t1.name ,t.x from t1
join t
select t2.name ,t.x from t2
join t
select t3.name ,t.x from t3
join t
使用场景：
如果你的业务中有些数据类似于数据字典，比如配置文件的配置，
常用业务的配置或者数据量不大很少变动的表，这些表往往不是特别大，
而且大部分的业务场景都会用到，那么这种表适合于Mycat全局表，无须对数据进行切分，
要在所有的分片上保存一份数据即可，Mycat 在Join *** 作中，业务表与全局表进行Join聚合会优先选择相同分片内的全局表join，
避免跨库Join，在进行数据插入 *** 作时，mycat将把数据分发到全局表对应的所有分片执行，在进行数据读取时候将会随机获取一个节点读取数据。
vim schema.xml
<table name="t_area" primaryKey="id" type="global" dataNode="sh1,sh2" />
后端数据准备
mysql -S /data/3307/mysql.sock
use taobao
create table t_area (id int not null primary key auto_increment,name varchar(20) not null)
mysql -S /data/3308/mysql.sock
use taobao
create table t_area (id int not null primary key auto_increment,name varchar(20) not null)
重启mycat
mycat restart
测试：
mysql -uroot -p123456 -h10.0.0.52 -P8066
use TESTDB
insert into t_area(id,name) values(1,'a')
insert into t_area(id,name) values(2,'b')
insert into t_area(id,name) values(3,'c')
insert into t_area(id,name) values(4,'d')
A
join
B
为了防止跨分片join，可以使用E-R模式
A join B
on a.xx=b.yy
join C
on A.id=C.id
<table name="A" dataNode="sh1,sh2" rule="mod-long">
<childTable name="B" joinKey="yy" parentKey="xx" />
</table>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）