对于 MySQL 数据库作为各个业务系统的存储介质，在系统中承担着非常重要的职责，如果数据库崩了，那么对于读和写数据库的操作都会受到影响。

前言

对于 MySQL 数据库作为各个业务系统的存储介质，在系统中承担着非常重要的职责，如果数据库崩了，那么对于读和写数据库的操作都会受到影响。如果不能迅速恢复，对业务的影响是非常大的。之前 B 站不是出过一次事故么，2 小时才恢复过来，详细可以看之前写的文章。

B 站崩了，总结下「高可用」和「异地多活」

上次折腾完 ELK 日志检索平台后，开发环境可以正常查询日志了。最近在做系统高可用相关的工作，这次我来分享下 MySQL 双主 + Keepalived 的高可用落地和踩坑之路。

一文带你搭建一套 ELK Stack 日志平台

一、方案选择

对于 MySQL 的高可用，主要分为两步，配置 MySQL 主主模式和 keepalived 软件。拓扑图如下所示：

MySQL 数据库的主主模式

两个数据库分别部署在两台服务器上，相互同步数据，但是只有一个提供给外部访问，当一个宕机后，另外一个可以继续提供服务，在没有 keepalived 软件的帮助下，只能手动切换

keepalived 监测、自动重启、流量切换

检测和重启的原理如下所示：

需要配置的内容如下：

二、主主复制的原理

对于 MySQL 的主主架构，其实原理就是两台服务器互为主从，双向复制。而复制的原理如下：

主从复制主要有以下流程：

1. 主库将数据的改变记录到 binlog 中；
2. 从库会在一定时间间隔内对master 的 binlog 进行检查，如果发生改变，则开始一个 I/O Thread 请求读取 master 中 binlog ；
3. 同时主库为每个 I/O 线程启动一个 dump 线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从库将启动 SQL 线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后 I/O Thread 和 SQL Thread 将进入睡眠状态，等待下一次被唤醒；

大白话就是：

从库会生成两个线程,一个 I/O 线程,一个 SQL 线程;

I/O 线程会去请求主库的 binlog，并将得到的 binlog 写到本地的 relay-log (中继日志)文件中;

主库会生成一个 dump 线程,用来给从库 I/O 线程传 binlog;

SQL 线程,会读取 relay log 文件中的日志,并解析成 SQL 语句逐一执行;

接下来我们先把 MySQL 的基础环境在两台 Ubuntu 服务器上搭建好，后续操作都是基于这个来做的。

三、配置 MySQL 环境

作为演示，我在本机启动了两台 Ubuntu 虚拟机，安装有 docker。因为我们的测试和生产环境是用 Docker 跑的，所以我将环境的镜像打包后，还原到我的虚拟机上面。

3.1 备份和还原 mysql 镜像

保存测试环境的 mysql 镜像

两台机器导入镜像

启动容器，需要注意的是需要映射本地文件夹。

-v 代表映射的文件夹，-d 表示后台运行，46b 代表镜像 id。

进入容器，连接 mysql，node1的mysql 密码是 123456，node2 是 123456

接下来我们配置 MySQL 的主从架构，需要注意的是后续搭建的主主架构是基于主从架构来的，区别就是修改了一部分配置。

四、配置 MySQL 的主从架构

拓扑结构：

4.1 修改主节点配置文件

修改 /home/hss/mysql/etc/mysql/my.cnf 文件

创建 /home/hss/mysql/data/log/mysql-bin 文件夹

创建 /home/hss/mysql/data/log/relay-bin 文件夹

给两个文件夹加上 777 权限，然后重启 MySQL 容器。

4.2 修改从节点配置文件

和主节点配置类似，需要修改 server_id = 12

4.3 添加主节点 mysql 账户信息

4.4 锁主库的表

FLUSH TABLES WITH READ LOCK;

4.5 查看二进制日志文件的位置

记住 File 和 Position，后面会用到。这里 File = mysql-bin.000008，Position = 1020。

4.6 备份数据库，导出为脚本文件

查看挂载目录下是否有生成 all_databases.sql 文件，如下图所示：

4.7 解除锁定表

4.8 从节点还原数据库

mysql -uroot -p -hlocalhost -P3306 < /var/lib/mysql/backup/all_databases.sql

4.9 设置同步信息

在 MySQL 命令行窗口中执行以下命令设置同步信息。这里就是配置主数据库的 IP 地址、Port、用户名、密码，二进制文件名，偏移量。

4.10 启动从数据库的复制线程

在 MySQL 命令行窗口中执行以下命令启动从数据库的复制线程。

4.11 查看从数据库的同步状态

如果 Slave_IO_Running 和 Slave_SQL_Running 显示 Yes，就表示启动同步成功。如下图所示：

在主库上执行以下命令显示当前连接过来的从库线程。

如下所示，Slave has read all relay log; wating for more updates，说明从库已经同步完了。

使用上面的两个命令，我们可以判断当前的复制情况。

4.12 验证同步功能

下面验证下主从节点之间是否能正常同步数据。

主节点创建 testdb 数据库和 member 表。

刷新下从节点，发现从节点自动创建了 member 表。如下图所示。

然后在主节点插入一条数据，刷新从节点后，发现从节点也自动创建了一条数据。

五、配置主主架构

5.1 步骤

配置主主架构就是在主从架构中交换下配置信息。步骤如下：

5.2 node2 节点上的操作

5.2.1 停止同步

STOP slave

5.2.2 添加主节点 mysql 账户信息

5.2.3 查看二进制日志文件和位置信息

SHOW MASTER STATUS

5.2.4 开启主从复制

start slave

5.2.5 查看同步状态

5.3 node 1 节点上的操作

5.3.1 设置同步信息

5.3.2 启动从数据库的复制线程

START salve

5.3.3 查看从数据库的同步状态

SHOW slave status \G

5.4 测试主主同步

node2 的 member 表增加一条数据 （2，zzz），node1 上同步成功

node 1 的 member 表增加一条数据（3，aaa），node2 上同步成功

六、搭建 keepalived 环境

6.1 Keepalived 的应用场景

Keepalived 软件在主主架构中，可以配置成两种应用场景：

这里我配置成第二种功能场景，保障 MySQL 服务的高可用。另外可以配置 MySQL 服务异常时，发送邮件给运维或开发人员，由他们检查服务器的状态。

6.2 使用 Keepalived 的原理

Keepalived 提供了一个虚拟 IP （简称 VIP)，对外提供访问。当客户端连接这个虚拟 IP 后，只会访问其中一个 MySQL。MySQL 节点故障后，keepalived 执行脚本进行重启，如果重启失败，脚本自动停掉 keepalived，备用节点自动切换为主节点。

keepalived 检测和重启的流程图如下：

6.3 安装 keepalived 软件

安装依赖、获取 keepalived 安装包、解压安装包、删除安装包。

配置 keepalived 软件

执行结果如下所示：

编译 keepalived 软件

执行结果如下所示：

对于 Ubuntu ，需要做一点特别的改动，创建链接

拷贝配置文件

修改配置文件 /etc/keepalived/keepalived.conf

改为

6.4 添加虚拟 IP

先用 ifconfig 查看当前的网卡，比如我的服务器上是 enp0s8。

将命令写到 /usr/local/script/vip.sh文件中。最好将 /usr/local/script/vip.sh文件添加到服务器的开机启动项中，将 Keepalived 服务设置为开机自启动（未写）。

6.5 修改配置文件

备份配置文件

修改配置文件

配置文件的内容如下：

编写异常处理脚本

内容如下，

给脚本分配权限

创建 logs 文件夹，给 logs 文件夹分配权限

重新加载配置文件

6.6 启动 keepalived

6.6.1 启动两台服务器上的 keepalived

启动 node2 节点：

启动 node1 节点：

我们可以通过这个命令查看 keepalived 进程

查看日志

6.7 测试 keepalived 是否会重启 mysql

停止 node2 上的 mysql 容器

查看 keepalived 状态，提示移除了 mysql 服务。

因为 keepalived 会每 2s 检查一次 MySQL 的状态，发现 MySQL 异常后，就会重启 mysql 容器。所以过几秒后，重新查看容器状态，会看到 mysql 容器重新启动了。

查看 keepalived 状态，执行 restart_mysql 成功

查看执行日志

问题：每 2s 会打印一次，文件可能会很大。需要执行定期删除。

6.8 测试 MySQL 节点切换

验证下当 MySQL 重启失败后，keepalived 自动停止后，客户端连接的 MySQL 是否会自动切到另外一个 MySQL 节点上。

首先用 mysql 客户端工具 navicat 连接虚拟 ip 地址，账号和密码就是 node 1 和 node2 的 mysql 账号密码（root/123456）

可以连接上，然后执行以下命令，查看当前虚拟 ip 连接的是哪个数据库

可以看到连接的是 node2 的容器的 id，说明 keepalived 已经通过虚拟 ip 连接到 node2 的 mysql 了，是正常工作的，node2 现在是作为主节点，node1 作为备用节点。

由于本地环境重新启动 MySQL 都是成功的，不会停掉 keepalived 服务。出于演示目的，我就直接停掉 keepalived 服务。

执行下面这个命令可以查看 keepalived 进程，发现已经没有了。（控制台显示的 grep --color=auto keepalived 表示是查找命令）

重新查询客户端的连接信息，发现已经切换到 92b （node1）机器上的 mysql 了。

再次查看 node1 上 keepalived 上的状态，再发送信息给

七、遇到的坑

7.1 密码不正确，无法登录的问题

密码不正确，设置跳过密码验证

修改 mysql 配置文件

添加一行配置，跳过 mysql 密码验证

重启容器

docker restart 9e6

重新计入 mysql 容器，连接 mysql，不需要密码就可以连接上 mysql。

修改登录密码

重启容器

7.2 没有映射 mysql 文件夹

拷贝 mysql 文件夹

7.3 mysql data 文件夹没有权限

7.4 安装依赖包失败

解决方案：更新包

7.5 更新包失败

解决方案：

修改配置文件

配置内容如下：

执行更新

依赖包版本太高

解决方案：

按照这个报错信息来进行降级，等号后面就是提示信息里括号的版本信息。

启动 keepalived 报错

解决方案：

再次启动，提示另外一个错误。

解决方案，因为 ubuntu 没有这个命令 /etc/rc.d/init.d/functions，所以需要添加一个命令链接

install gcc 出现问题

切换回 ubuntu 官方源

启动 keepalived 报错 keepalived_script

解决方案：

配置文件的 global_defs 配置里面增加 script_user root

执行脚本失败

给脚本添加权限。