Keepalived＋双主实现mysql高可用

生产环境中一台 mysql 主机存在单点故障，所以我们要确保 mysql 的高可用性，即两台 MySQL服务器如果其中有一台 MySQL 服务器挂掉后，另外一台能立马接替其进行工作。

本次主要介绍了利用 keepalived 实现 MySQL 数据库的高可用。

基本思路：

Keepalived+mysql双主来实现MySQL-HA，我们必须保证两台MySQL数据库的数据完全一样。

基本思路是两台 MySQL 互为主从关系，通过 Keepalived 配置虚拟 IP，实现当其中的一台MySQL 数据库宕机后，应用能够自动切换到另外一台 MySQL 数据库，保证系统的高可用。

实现高可用的基本环境：

OS：centos7.0 x86_64

Mysql 版本：mysql 5.7.22

Keepalived: keepalived-2.0.6

Mysql-vip:192.168.1.100

Mysql-master1:192.168.1.101

Mysql-master2:192.168.1.102

一、配置两台mysql主主同步

主从同步的过程：

该过程的第一部分就是master 记录二进制日志。在每个事务更新数据完成之前，master 在二日志记录这些改变。MySQL 将事务写入二进制日志。在事件写入二进制日志完成后，master通知存储引擎提交事务。

下一步就是slave 将 master 的 binary log 拷贝到它自己的中继日志。首先，slave 开始一个工作线程——I/O 线程。I/O 线程在 master 上打开一个普通的连接，然后开始 binlog dump process。Binlog dump process 从 master 的二进制日志中读取事件，如果已经同步了 master，它会睡眠并等待 master 产生新的事件。I/O 线程将这些事件写入中继日志。

SQL slave thread（SQL 从线程）处理该过程的最后一步。SQL 线程从中继日志读取事件，并重放其中的事件而更新 slave 的数据，使其与 master 中的数据一致。只要该线程与 I/O 线程保持一致，中继日志通常会位于 OS 的缓存中，所以中继日志的开销很小。

注：主主同步就是两台机器互为主的关系，在任何一台机器上写入都会同步。

若 mysql 主机开启了防火墙，需要关闭防火墙或创建规则。

1、修改mysql配置文件

两台 MySQL 均要开启 binlog 日志功能，开启方法：在 MySQL 配置文件[MySQLd]段中加上log_bin=MySQL-bin选项，两台 MySQL 的 server-ID 不能一样，默认情况下两台 MySQL 的serverID 都是 1，需将其中一台修改为 2 即可。

master1 中有关复制的配置如下：

master2 中有关复制的配置如下：

注：master1 和 master2 只有 server-id 不同和 auto-increment-offset 不同。

2、将 master1 设为 master2 的主服务器

在 master1 主机上创建授权账户，允许在 master2(192.168.1.102)主机上连接

查看 master1 的当前 binlog 状态信息

在 master2 上将 master1 设为自已的主服务器并开启 slave 功能。

查看从的状态，mysql>show slave status\G;以下两个值必须为 yes,代表从服务器能正常连接主服务器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

3、将 master2 设为 master1 的主服务器

在 master2 主机上创建授权账户，允许在 master1(192.168.1.101)主机上连接

查看 master2 的当前 binlog 状态信息

在 master1 上将 master2 设为自已的主服务器并开启 slave 功能。

查看从的状态，以下两个值必须为 yes,代表从服务器能正常连接主服务器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

4、测试主主同步

在 master1 上创建要同步的数据库如 test_db，并在 test_db 中创建一张测试表如 tab1

查看 master2 主机是否同步了 master1 上的数据变化

在 master2 主机上向 tab1 表中插入数据

查看 master1 主机是否同步了 master2 上的数据变化

二、配置keepalived实现高可用

keepalived 是以 VRRP 协议为实现基础的，VRRP 全称 Virtual Router 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 协议的。

1、在 master1 和 master2 上安装软件包 keepalived

在编译安装 Keepalived 之前，必须先安装内核开发包 kernel-devel 以及 openssl-devel、popt-devel 等支持库。

编译安装 Keepalived

执行 make install 操作之后，会自动生成/etc/init.d/keepalived 脚本文件，但还需要手动添加为系统服务，这样就可以使用 service、chkconfig 工具来keepalived 服务程序进行管理了。

Master2 主机也完成 keepalived 安装，与 master1 一样，安装过程略

注：若开启了防火墙，需要关闭防火墙或创建规则。

2、修改 Keepalived 的配置文件

keepalived 只有一个配置文件 keepalived.conf，里面主要包括以下几个配置区域，分别是global_defs、vrrp_instance 和 virtual_server。

global_defs：主要是配置故障发生时的通知对象以及机器标识。

vrrp_instance：用来定义对外提供服务的 VIP 区域及其相关属性。

virtual_server：虚拟服务器定义

master1 主机上的 keepalived.conf 文件的修改：

启动 keepalived 服务

#/etc/init.d/keepalived start

Master2 主机上的 keepalived.conf 文件的修改：

启动 keepalived 服务

#/etc/init.d/keepalived start

3、#mkdir /etc/keepalived/bin

vi /etc/keepalived /bin/mysql.sh，内容如下

Master2 主机完成相同的操作

4、测试

在 master1 和 master2 分别执行 ip addr show dev eth0 命令查看 master1 和 master2 对 VIP（群集虚拟 IP）的控制权。

Master1 主的查看结果：

Master2 主的查看结果：

从上图可以看出 master1 是主服务器，master2 为备用服务器。

停止master1的 MySQL 服务，看 keepalived 健康检查程序是否会触发我们编写的脚本

Master2 主的查看结果：

通过测试说明在主服务上停止 MySQL 服务，触发了我们编写的脚本，进行自动故障切换。

5、MySQL 远程登录测试

我们找一台安装有 MySQL 客户端，然后登录 VIP，看是否能登录，在登录之前两台 MySQL服务器都要授权允许从远程登录。

在客户端上测试登录

上图显示说明在客户端访问 VIP 地址，由 master1 主机提供响应的，因为 master1 当前是主服务器，

将 master1 的 mysql 服务停止，在客户端执行 show variables like ‘server_id’;

上图显示说明在客户端的查询请求是由 master2 主机响应的。故障切换成功。

Keepalived+mysql 双主一般来说，中小型规模的时候，采用这种架构是最省事的。在 master 节点发生故障后，利用 keepalived 的高可用机制实现快速切换到备用节点。

在这个方案里，有几个需要注意的地方：

1.采用 keepalived 作为高可用方案时，两个节点最好都设置成 BACKUP 模式，避免因为意外情况下（比如脑裂）相互抢占导致往两个节点写入相同数据而引发冲突；

2.把两个节点的 auto_increment_increment（自增步长）和 auto_increment_offset（自增起始值）设成不同值。其目的是为了避免 master 节点意外宕机时，可能会有部分 binlog 未能及时复制到 slave 上被应用，从而会导致 slave 新写入数据的自增值和原先 master 上冲突了，因此一开始就使其错开；当然了，如果有合适的容错机制能解决主从自增 ID 冲突的话，也可以不这么做；

3.slave 节点服务器配置不要太差，否则更容易导致复制延迟。作为热备节点的 slave 服务器，硬件配置不能低于 master 节点；

4.如果对延迟问题很敏感的话，可考虑使用 MariaDB 分支版本，或者直接上线 MySQL 5.7 最新版本，利用多线程复制的方式可以很大程度降低复制延迟；