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线程工作状态进行监控；
答：修改vip 或者vip 对应的hostname详细步骤如下：
在oracle 10g 和 11g 的Clusterware 环境中，客户端使用vip(Virtual IP)来连接数据库，客户端应用程序通过vip访问对应的节点上的数据库实例。每个节点都要有一个vip，这些vip是静态的ip地址，必须与公共网络属于同一个子网。每一个vip也要对应一个主机名,而且对于客户端来说,这个主机名应该能够被解析为VIP.VIP通过DNS,/etc/hosts文件来解析(11GR2 可以使用GNS)，在安装GI软件时候，会提示为每一个节点填写对应的VIP和VIP对应的hostname，vip信息会存储在OCR和HA架构相关的组件中。
通常来说，VIP的修改需要在规定的时间窗口内，cluster 停止服务。然而对于某种情况下，是不需要停机时间，比如只是修改一个节点的vip维护 *** 作只要在那个节点上就可以了，而不必停止整个cluster。
从10.2.0.3 以来，oracle 去除了ASM/DATABSE对vip的依赖关系，这样对vip的修改可以在不必停止ASM/DATABASE实例的情况下进行，需要做的仅仅是与这个节点连接的客户端受到影响。
实验环境：
版本：
Clusterware ：11.2.0.2
database：11.2.0.1
修改vip的 *** 作步骤：
旧vip：
10.10.10.201 rac1-vip
10.10.10.202 rac2-vip
新vip：
10.250.7.111 rac1-vip
10.250.7.112 rac2-vip
子网 10.250.7.0
掩码 255.255.255.0
1 确定vip
对于 10g and 11gR1, 以CRS的属主:
$ srvctl config nodeapps -n -a
比如：
$ srvctl config nodeapps -n racnode1 -a
VIP exists.: /racnode1-vip/101.17.80.184/255.255.254.0/eth1
对于 11gR2, 以Grid 属主:
$ srvctl config nodeapps -a
grid@rac1:/home/grid>srvctl config nodeapps -a
网络存在: 1/10.250.7.0/255.255.255.0/eth0, 类型 static
VIP 存在: /rac1-vip/10.10.10.201/10.250.7.0/255.255.255.0/eth0, 托管节点 rac1
VIP 存在: /rac2-vip/10.10.10.202/10.250.7.0/255.255.255.0/eth0, 托管节点 rac2
2. 确定VIP的状态
grid@rac1:/home/grid>crs_stat -t | grep vip
Name Type TargetState Host
------------------------------------------------------------
ora.rac1.vip ora....t1.type ONLINEONLINErac1
ora.rac2.vip ora....t1.type ONLINEONLINErac2
ora.scan1.vip ora....ip.type ONLINEONLINErac1
grid@rac1:ifconfig -a
.....省略.....
eth0:2Link encap:Ethernet HWaddr 00:50:56:8F:25:0A
inet addr:10.10.10.201 Bcast:10.250.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x2400 Memory:d8960000-d8980000
.....省略.....
Stopping Resources
3. 停止nodeapps资源和所有依赖于VIP的资源(如果有计划的中断所有服务，则停止ASM/DB 实例)
10g and 11gR1,以CRS的属主:
$ srvctl stop asm -n
$ srvctl stop instance -d -i
$ srvctl stop nodeapps -n
比如：
$ srvctl stop asm -n racnode1
$ srvctl stop instance -d RACDB -i RACDB1
$ srvctl stop nodeapps -n racnode1
11gR2,以Grid属主:
$ srvctl stop instance -d -n
$ srvctl stop vip -n -f
grid@rac1:srvctl stop database -d rac -o immediate
PRCD-1027 : 无法检索数据库 rac
PRCD-1229 : 尝试访问数据库 rac 的配置时被拒绝, 因为其版本 11.2.0.1.0 不同于程序版本 11.2.0.2.0。请改从 /opt/rac/oracle/11.2.0/dbs 运行程序。
oracle@rac1:/home/oracle>srvctl stop database -d rac -o immediate
grid@rac1:/home/grid>srvctl stop vip -n rac1 -f -v
已成功停止 VIP。
grid@rac1:/home/grid>srvctl stop vip -n rac2 -f -v
已成功停止 VIP。
Note: 在 11GR2版本中，-f选项是必须的，否则会报如下错误：
PRCR-1014 : Failed to stop resource ora.rac1.vip
PRCR-1065 : Failed to stop resource ora.rac1.vip
CRS-2529: Unable to act on 'ora.rac1.vip' because that would require stopping or relocating 'ora.LISTENER.lsnr', but the force option was not specified
...
grid@rac1:/home/grid>srvctl stop listener -n rac1
PRCC-1017 : LISTENER 已在 rac1 上停止
PRCR-1005 : 资源 ora.LISTENER.lsnr 已停止
grid@rac1:/home/grid>srvctl stop listener -n rac2
PRCC-1017 : LISTENER 已在 rac2 上停止
PRCR-1005 : 资源 ora.LISTENER.lsnr 已停止
为了防止变更未被确认，而asm 或者db 实例的自动启动，需要将此自动重启功能暂时禁用。
$ srvctl disable database -d
$ srvctl disable asm -n (对于11.2 版本之前的)
$ srvctl disable nodeapps (使用与 11.2 版本以后的)
而我执行srvctl disable nodeapps命令时遇到如下情况(因为vip服务已经停止了)。不会影响最终的 *** 作。
grid@rac1:/home/grid>srvctl disable nodeapps
PRKO-2409 : GSD 已在节点上禁用: rac1,rac2
PRCR-1071 : 无法注册或更新 资源 ora.rac1.vip
CRS-0245: User doesn't have enough privilege to perform. the operation
PRCR-1071 : 无法注册或更新 资源 ora.net1.network
CRS-0245: User doesn't have enough privilege to perform. the operation
4.确认VIP是否已经offline，并且不再绑定到公共网卡上：
grid@rac1:/home/grid>crs_stat -t | grep vip
ora.rac1.vip ora....t1.type OFFLINE OFFLINE
ora.rac2.vip ora....t1.type OFFLINE OFFLINE
ora.scan1.vip ora....ip.type ONLINEONLINErac1
使用 ifconfig -a
5 修改VIP和对应的属性值，确保先在OS上做相应的变更 比如/etc/hosts 或者DNS。如果网卡改变了，先确保新的网卡可用。
旧vip：
10.10.10.201 rac1-vip
10.10.10.202 rac2-vip
新vip
10.250.7.111 rac1-vip
10.250.7.112 rac2-vip
子网 10.250.7.0
掩码 255.255.255.0
6. 修改VIP资源
以root用户执行如下命令：
[root@rac1 ~]# /opt/11202/11.2.0/grid/bin/srvctl modify nodeapps -n rac1 -A rac1-vip/255.255.255.0/eth0
[root@rac1 ~]# /opt/11202/11.2.0/grid/bin/srvctl modify nodeapps -n rac2 -A rac2-vip/255.255.255.0/eth0
Note 1: 对于windows平台，如果网卡名称有空格，必须使用 ""
比如：
>srvctl modify nodeapps -n racnode1 -A 110.11.70.11/255.255.255.0/"Local Area Connection 1
Note 2: 从 11.2 开始,VIP依赖于network资源(ora.net1.network),OCR 仅仅只是记录VIP 的hostname或者vip 的ip地址。vip的网络属性比如子网和掩码是记录在network资源里的。
From 11.2.0.2起 , 可以使用srvctl modify network 命令修改网络资源信息
grid@rac1:/home/grid>srvctl modify network -h
修改 Oracle Clusterware 中的网络配置。
用法: srvctl modify network [-k ] [-S /[/if1[|if2...]]] [-w ] [-v]
-k 网络编号 (默认编号为 1)
-S //[if1[|if2...]] 网络的 NET 地址说明
-w网络类型 (static, dhcp, mixed)
-h 输出用法
-v 详细输出
以root用户：
# srvctl modify network -k 1 -S 110.11.70.0/255.255.255.0/eth2
7. 确认变更：
grid@rac1:/home/grid>srvctl config nodeapps -a
网络存在: 1/10.250.7.0/255.255.255.0/eth0, 类型 static
VIP 存在: /rac1-vip/10.250.7.111/10.250.7.0/255.255.255.0/eth0, 托管节点 rac1
VIP 存在: /rac2-vip/10.250.7.112/10.250.7.0/255.255.255.0/eth0, 托管节点 rac2
8. 重新启动nodeapps资源和相关依赖资源
grid@rac1:/home/grid>srvctl enable nodeapps
PRKO-2415 : VIP 已在节点上启用: rac1,rac2
PRKO-2416 : 网络资源已启用。
oracle@rac1:/home/oracle>srvctl enable database -d rac
grid@rac1:/home/grid>
grid@rac1:/home/grid>srvctl start listener -n rac2
grid@rac1:/home/grid>srvctl start listener -n rac1
grid@rac1:/home/grid>
oracle@rac1:/home/oracle>
oracle@rac1:/home/oracle>srvctl start database -d rac
grid@rac1:/home/grid>
9. 查看新的VIP的状态
grid@rac1:/home/grid>crs_stat -t | grep vip
ora.rac1.vip ora....t1.type ONLINEONLINErac1
ora.rac2.vip ora....t1.type ONLINEONLINErac2
ora.scan1.vip ora....ip.type ONLINEONLINErac1
grid@rac1:/home/grid>
grid@rac1:/home/grid>
grid@rac1:/home/grid>/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:56:8F:25:0A
inet addr:10.250.7.225 Bcast:10.250.7.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe8f:250a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:560742 errors:0 dropped:0 overruns:0 frame.:0
TX packets:1472284 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:56118003 (53.5 MiB) TX bytes:126169027 (120.3 MiB)
Base address:0x2400 Memory:d8960000-d8980000
eth0:1Link encap:Ethernet HWaddr 00:50:56:8F:25:0A
inet addr:10.250.7.210 Bcast:10.250.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x2400 Memory:d8960000-d8980000
eth0:2Link encap:Ethernet HWaddr 00:50:56:8F:25:0A
inet addr:10.250.7.111 Bcast:10.250.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x2400 Memory:d8960000-d8980000
eth1 Link encap:Ethernet HWaddr 00:50:56:8F:6F:49
inet addr:10.10.10.101 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe8f:6f49/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6842717 errors:0 dropped:0 overruns:0 frame.:0
TX packets:4120949 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4798726508 (4.4 GiB) TX bytes:1472194319 (1.3 GiB)
Base address:0x2440 Memory:d8980000-d89a0000
eth1:1Link encap:Ethernet HWaddr 00:50:56:8F:6F:49
inet addr:169.254.51.141 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x2440 Memory:d8980000-d89a0000
grid@rac1:/home/grid>
对于11gR2,只是修改vip的hostname 而不修改其ip地址和vip的其他属性不变：
1.修改VIP 使其指向另一个可用的 hostname,比如rac1
# srvctl modify nodeapps -n racnode1 -A rac2-vip/255.255.255.0/eth2
2.修改 VIP 指定新的hostname
# srvctl modify nodeapps -n racnode1 -A rac1-nvip/255.255.255.0/eth2
3. 确定 USR_ORA_VIP 的值:
# crsctl stat res ora.rac1.vip
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）