1 前言

  • 生产环境中一台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数据库,保证系统的高可用。

2 环境

  • OS version:CentOS7
  • MySQL version:mysql-5.7.28-el7-x86_64.tar.gz
  • keepalived version:keepalived-2.0.20.tar.gz
  • MySQL-master1:192.168.200.88
  • MySQL-master2: 192.168.200.89
  • VIP:192.168.200.200
  • Client:192.168.200.87

!!!关闭防火墙,关闭selinux,时间同步!!!

3 二进制方式安装MySQL

3.1 安装相关包

# yum -y install libaio

3.2 创建用户和组

# groupadd mysql && useradd -r -g mysql -s /bin/false mysql

3.3 准备程序文件

# cd /usr/local/src/
# tar xf mysql-5.7.28-el7-x86_64.tar.gz -C /usr/local/
# cd /usr/local/
# ln -s mysql-5.7.28-el7-x86_64/ mysql
# chown -R mysql.mysql mysql

3.4 准备环境变量

# echo 'PATH=/usr/local/mysql/bin:$PATH' > /etc/profile.d/mysql.sh
# source /etc/profile.d/mysql.sh

3.5 生成数据库文件

# mysqld --initialize --user=mysql --datadir=/data/mysql
# mysqld --initialize --user=mysql --datadir=/data/mysql
···省略···
2020-06-03T08:47:23.556966Z 1 [Note] A temporary password is generated for root@localhost: (1BfO&>qmvo,  #注意这个生成的临时密码,后面需要用到

3.6 准备配置文件

# cp /etc/my.cnf{,.bak}
# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
log-error=/data/mysql/mysql.log
pid-file=/data/mysql/mysql.pid

[client]
socket=/data/mysql/mysql.sock

3.7 准备服务脚本和启动服务

# cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqld
# chkconfig --add mysqld
# service mysqld start

3.8 修改初始秘密

# mysqladmin -uroot -p'(1BfO&>qmvo,' password 123.com
初始密码是刚才临时生成的那个

3.9 测试登录

# mysql -uroot -p123.com
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 5.7.28-log MySQL Community Server (GPL)

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

以上操作在另一台MySQL也是一样,需要注意的是临时生成的密码要修改。

4 配置2台MySQL实现主主同步

MySQL主主复制+keepalived高可用方案实现_第1张图片

  • 该过程的第一部分就是 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 主机开启了防火墙,需要关闭防火墙或创建规则。

4.1 修改MySQL配置文件

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

4.1.1 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

4.1.2 master2中有关复制的配置

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

注: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=数据库名”配置项(可以添加多个)来指定要同步的数据库

4.2 将master1设置为master2的主服务器

4.2.1 创建授权账户

mysql> GRANT REPLICATION SLAVE ON *.* TO 'rep'@'192.168.200.89' IDENTIFIED BY '123.com'

4.2.2 查看master1当前的binlog状态信息

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

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

mysql> CHANGE MASTER TO
    -> MASTER_HOST='192.168.200.88',
    -> MASTER_USER='rep',
    -> MASTER_PASSWORD='123.com',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mysql-bin.000001',
    -> MASTER_LOG_POS=154;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

4.2.4 查看同步状态

MySQL主主复制+keepalived高可用方案实现_第2张图片
Slave_IO_Running和Slave_SQL_Running这两个值必须为Yes,代表从服务器能正常连接服务器

4.3 将master2设置为master1的主服务器

4.3.1 创建授权账户

mysql> GRANT REPLICATION SLAVE ON *.* TO 'rep'@'192.168.200.88' IDENTIFIED BY '123.com'

4.3.2 查看master2当前的binlog状态信息

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

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

mysql> CHANGE MASTER TO
    -> MASTER_HOST='192.168.200.89',
    -> MASTER_USER='rep',
    -> MASTER_PASSWORD='123.com',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mysql-bin.000001',
    -> MASTER_LOG_POS=154;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

4.3.4 查看同步状态

MySQL主主复制+keepalived高可用方案实现_第3张图片

4.4 测试主主同步

在master1上创建要同步的数据库如test_db,并在 test_db 中创建一张测试表如 tab1
MySQL主主复制+keepalived高可用方案实现_第4张图片
查看 master2 主机是否同步了 master1 上的数据变化
MySQL主主复制+keepalived高可用方案实现_第5张图片
从上图可以看出 master2 同步了 master 的数据变化
在 master2 主机上向 tab1 表中插入数据
MySQL主主复制+keepalived高可用方案实现
在 master1 主机查看是否同步了 master2 上的数据变化
MySQL主主复制+keepalived高可用方案实现_第6张图片
现在任何一台 MySQL 上更新数据都会同步到另一台 MySQL,MySQL 同步完成。
注:若主 MYSQL 服务器已经存在,只是后期才搭建从 MYSQL 服务器,在置配数据同步前应先将主 MYSQL 服务器的要同步的数据库拷贝到从 MYSQL 服务器上(如先在主 MYSQL 上备份数据库,再用备份在从 MYSQL 服务器上恢复)

5 安装配置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 负责健康检查,包括常见的各种检查方式(方式1:tcp_check工作第四层。方式2:http_get,工作在第五层,向指定的URL 执行 http 请求,将得到的结果用 md5 加密并与指定的 md5 值比较看是否匹配,不匹配则从服务器池中移除。方式3:ssl_get:与 http_get 相似。方式4:misc_check:用脚本来检测。方式5:smtp_check:用来检测邮件服务的smtp。)vrrp 模块是来实现 VRRP 协议的。

5.1 安装keepalived

以下操作在master1和master2都是一样的

# tar xf keepalived-2.0.20.tar.gz
# cd keepalived-2.0.20/
# ./configure --prefix=/apps/keepalived
# make -j $(lscpu | awk 'NR==4{print $2}') && make install

5.2 修改keepalived配置文件

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

  • global_defs:主要是配置故障发生时的通知对象以及机器标识。
  • vrrp_instance:用来定义对外提供服务的 VIP 区域及其相关属性。
  • virtual_server:虚拟服务器定义

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

# mkdir /etc/keepalived
# cp /apps/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived //!表示注释

global_defs {
   router_id mysql-1 //表示运行 keepalived 服务器的一个标识
}

vrrp_instance VI_1 {
    state BACKUP //指定keepalived的角色,两台配置此处均是BACKUP,设为BACKUP将根据优先级决定主或从
    interface eth0 //指定 HA 监测网络的接口
    virtual_router_id 51 //虚拟路由标识,这个标识是一个数字(取值在 0-255 之间,用来区分多个
instance 的 VRRP 组播),同一个 vrrp 实例使用唯一的标识,确保和 master2 相同,同网内不同集群此项必须不同,否则发生冲突。
    priority 100 //用来选举 master 的,要成为 master,该项取值范围是 1-255(在此范围
之外会被识别成默认值 100),此处 master2 上设置为 50
    advert_int 1 //发 VRRP 包的时间间隔,即多久进行一次 master 选举(可以认为是健康查
检时间间隔)
    authentication { //认证区域,认证类型有 PASS 和 HA(IPSEC),推荐使用 PASS(密码只识别前 8 位)
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {  //VIP 区域,指定 vip 地址
        192.168.200.200 
    }
}
virtual_server 192.168.200.200 3306 { //设置虚拟服务器,需要指定虚拟 IP 地址和服务端口,
IP 与端口之间用空格隔开
    delay_loop 2 //设置运行情况检查时间,单位是秒
    lb_algo rr  //设置后端调度算法,这里设置为 rr,即轮询算法
    lb_kind DR //设置 LVS 实现负载均衡的机制,有 NAT、TUN、DR 三个模式可选
    persistence_timeout 50 //会话保持时间,单位是秒。这个选项对动态网页是非常有用的,为集群系统中的 session 共享提供了一个很好的解决方案。有了这个会话保持功能,用户的请求会被一直分发到某个服务节点,直到超过这个会话的保持时间。
    protocol TCP //指定转发协议类型,有 TCP 和 UDP 两种
    real_server 192.168.200.88 3306 { //配置服务节点 1,需要指定 real server 的真实 IP 地址和
端口,IP 与端口之间用空格隔开
        weight 1  //配置服务节点的权值,权值大小用数字表示,数字越大,权值越高,设置权
值大小为了区分不同性能的服务器
        notify_down /etc/keepalived/bin/mysql.sh //检测到 realserver 的 mysql 服务 down 后执行的脚本
        TCP_CHECK {
           connect_timeout 3  //连接超时时间
           nb_get_retry 3 //重连次数
           delay_before_retry 3 //重连间隔时间
           connect_port 3306 //健康检查端口
        }
    }
}

5.2.2 master2主机上的keepalived.conf文件修改

Master2 主机的 keepalived.conf 文件配置与 master1 基本相同,只是 router_id,priority,
real_server 三处不同,其他配置都相同

# mkdir /etc/keepalived
# cp /apps/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   router_id mysql-2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.200
    }
}
virtual_server 192.168.200.200 3306 {
    delay_loop 2
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
    real_server 192.168.200.89 3306 {
        weight 1
        notify_down /etc/keepalived/bin/mysql.sh
        TCP_CHECK {
           connect_timeout 3
           nb_get_retry 3
           delay_before_retry 3
           connect_port 3306
        }
    }
}

5.2.3 在master1和master2上面分别启动keepalived并设置开机启动

# systemctl enable --now keepalived

5.3 在master1和master2上添加检测脚本

作用是当 mysql 停止工作时自动关闭本机的keepalived,从而实现将故障机器剔除(因为每台机器上 keepalived 只添加了本机为 realserver)当 mysqld 正常启动起来后,要手动启动 keepalived 服务。

# mkdir /etc/keepalived/bin
# cat /etc/keepalived/bin/mysql.sh 
#!/bin/bash
systemctl stop keepalived
(/sbin/ifdown eth0 && /sbin/ifup eth0)
# chmod +x /etc/keepalived/bin/mysql.sh

6 测试

在 master1 和 master2 分别执行 ip addr show dev eth0 命令查看 master1 和 master2 对 VIP(群集虚拟 IP)的控制权。
master1
MySQL主主复制+keepalived高可用方案实现_第7张图片
master2
MySQL主主复制+keepalived高可用方案实现_第8张图片
从上图可以看出 master1 是主服务器,master2 为备用服务器。

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

6.1.1 停止 master1 主机的 mysql 服务

MySQL主主复制+keepalived高可用方案实现_第9张图片

6.1.2 对应的日志也有详细的输出

MySQL主主复制+keepalived高可用方案实现_第10张图片

6.1.3 查看master2上是否有vip

MySQL主主复制+keepalived高可用方案实现

6.1.4 相关的日志信息

MySQL主主复制+keepalived高可用方案实现
这说明在主服务上停止 MySQL 服务,触发了我们编写的脚本,进行自动故障切换。

6.2 MySQL 远程登录测试

6.2.1 在master1和master2上授权

([email protected]) [(none)] 03:26:45> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123.com';
([email protected]) [(none)] 03:26:45> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123.com';

6.2.2 在客户端测试登录

MySQL主主复制+keepalived高可用方案实现_第11张图片
上图显示说明在客户端访问 VIP 地址,由 master1 主机提供响应的,因为 master1 当前是主服务器,将 master1 的 mysql 服务停止,在客户端执行 show variables like 'server_id';
MySQL主主复制+keepalived高可用方案实现_第12张图片
上图显示说明在客户端的查询请求是由 master2 主机响应的。故障切换成功。

7 总结:

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 最新版本,利用多线程复制的方式可以很大程度降低复制延迟;