keepalived+双主实现数据库的高可用

生产环境中一台 mysql 主机存在单点故障，因此咱们要确保 mysql 的高可用性，即两台 MySQL 服务器若是其中有一台 MySQL 服务器挂掉后，另一台能立马接替其进行工做。 MySQL 的高可用方案通常有以下几种：

keepalived+双主，MHA，PXC，MMM，Heartbeat+DRBD 等，比较经常使用的是 keepalived+双主， MHA 和 PXC。

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

Keepalived+mysql双主来实现MySQL-HA，咱们必须保证两台MySQL数据库的数据彻底同样， 基本思路是两台 MySQL 互为主从关系，经过 Keepalived 配置虚拟 IP，实现当其中的一台 MySQL 数据库宕机后，应用可以自动切换到另一台 MySQL 数据库，保证系统的高可用。

拓扑环境

OS：centos6.5 x86_64

Mysql 版本：mysql 5.5.38

Keepalived: keepalived-1.2.20

Mysql-vip:192.168.1.100

Mysql-master1:192.168.1.101

Mysql-master2:192.168.1.102

1、配置两台 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 主机开启了防火墙，须要关闭防火墙或建立规则。

 

一、修改 MySQL 配置文件 两台 MySQL 均要开启 binlog 日志功能，

开启方法：在 MySQL 配置文件[MySQLd]段中加上 log-bin=MySQL-bin 选项，

两台 MySQL 的 server-ID 不能同样，默认状况下两台 MySQL 的 serverID 都是 1，需将其中一台修改成 2 便可。

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

log-bin = mysql-bin

binlog_format = mixed

server-id = 1

relay-log = relay-bin

relay-log-index = slave-relay-bin.index

auto-increment-increment = 2

auto-increment-offset = 1

重启 mysqld 服务

#service mysqld restart master

2 中有关复制的配置以下：

log-bin = mysql-bin

binlog_format = mixed

server-id = 2

relay-log = relay-bin

relay-log-index = slave-relay-bin.index

auto-increment-increment = 2

auto-increment-offset = 2

重启 mysqld 服务

#service mysqld restart 

 

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

mysql 中有自增加字段，在作数据库的主主同步时须要设置自增加的两个相关配置：

auto_increment_offset 和 auto_increment_increment。

auto-increment-increment 表示自增加字段每次递增的量，其默认值是 1。它的值应设为整个 结构中服务器的总数，本案例用到两台服务器，因此值设为 2。

auto-increment-offset 是用来设定数据库中自动增加的起点(即初始值)，由于这两能服务器都 设定了一次自动增加值 2，因此它们的起点必须得不一样，这样才能避免两台服务器数据同步 时出现主键冲突，

注：能够在 my.cnf 文件中添加“binlog_do_db=数据库名”配置项（能够添加多个）来指定 要同步的数据库

 

 

二、将 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

三、将 master2 设为 master1 的主服务器 在 master2 主机上建立受权帐户，容许在 master1(192.168.1.101)主机上链接

查看 master2 的当前 binlog 状态信息

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

 

 查看从的状态，如下两个值必须为 yes,表明从服务器能正常链接主服务器 Slave_IO_Running:Yes Slave_SQL_Running:Yes

 

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

 

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

 

 从上图能够看出 master2 同步了 master 的数据变化

 

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

 

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

 

如今任何一台 MySQL 上更新数据都会同步到另外一台 MySQL，MySQL 同步完成。

注：若主 MYSQL 服务器已经存在，只是后期才搭建从 MYSQL 服务器，在置配数据同步前应 先将主 MYSQL 服务器的要同步的数据库拷贝到从 MYSQL 服务器上（如先在主 MYSQL 上备 份数据库，再用备份在从 MYSQL 服务器上恢复）

 

（keepalived）

下面咱们就完成 keepalived 的高可用性。 keepalived 是集群管理中保证集群高可用的一个软件解决方案，其功能相似于 heartbeat，用 来防止单点故障 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 协议的。

 2、keepalived 的安装配置

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

安装 keepalived 软件包与服务控制

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

若没有安装则经过 rpm 或 yum 工具进行安装

编译安装 Keepalived

注意：如不知道 keepalived 须要哪些依赖包，可到下载后的源码解压目录下查看 INSTALL 文 件内容，+ 执行 make install 操做以后，会自动生成/etc/init.d/keepalived 脚本文件，

 

 

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

########################################################

 

（后边有修改好的）

 

 

master1 主机上有关 keepalived.conf 文件的具体配置以下：

启动 keepalived 服务

#/etc/init.d/keepalived start

 

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

可使用 scp 命令把 server1 主机上配置好的 keepalived.conf 文件拷贝到 server2 主机，只要 作简单修改便可，以下图所示：

启动 keepalived 服务

#/etc/init.d/keepalived start

 

三、#mkdir /etc/keepalived/bin

vi /etc/keepalived /bin/mysql.sh，内容以下：（根据须要输入最后一行）

Master2 主机完成相同的操做

 

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

Master1 主的查看结果：

 

Master2 主的查看结果：

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

中止 MySQL 服务，看 keepaliv ed 健康检查程序是否会触发咱们编写的脚本 中止 master1 主机的 mysql 服务

Master2 主的查看结果：

这说明在主服务上中止 MySQL 服务，触发了咱们编写的脚本，进行自动故障切换。 MySQL 远程登陆测试

 

总结： 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 最 新版本，利用多线程复制的方式能够很大程度下降复制延迟；