MySQL 高可用架构：Keepalived 双主复制实战指南

在高并发、高可用的互联网应用中，数据库的稳定性和可靠性至关重要。当单点 MySQL 数据库出现故障时，整个系统都将受到影响。本文将介绍如何利用 MySQL 的主主复制结合 Keepalived 技术，构建一个高可用的 MySQL 数据库集群，保障业务的连续性和数据的安全性。这种方案能够应对单台数据库服务器宕机的情况，并且通过 Keepalived 提供的虚拟 IP 地址（VIP），应用程序无需修改连接配置即可继续访问数据库服务。

问题场景重现

假设你负责一个电商平台的数据库运维，目前使用的是单台 MySQL 数据库。随着业务的快速发展，单台数据库的压力越来越大，同时存在单点故障的风险。如果数据库服务器宕机，将会导致整个电商平台无法访问，造成巨大的经济损失。因此，需要构建一个高可用的数据库集群，提高数据库的可靠性和容错能力。

单点故障带来的挑战

• 数据丢失：单点故障可能导致数据丢失，尤其是在没有及时备份的情况下。
• 服务中断：数据库宕机将直接导致依赖于数据库的应用服务中断。
• 性能瓶颈：单台数据库服务器在高并发场景下容易出现性能瓶颈，影响用户体验。

底层原理深度剖析

MySQL 主主复制原理

MySQL 主主复制是指两台或多台 MySQL 服务器互相作为对方的主服务器和从服务器，实现数据的双向同步。每台服务器都可以接受写操作，并将数据同步到其他服务器。这种架构可以提高数据库的可用性和读写性能。

Keepalived 高可用原理

Keepalived 是一个高可用的解决方案，基于 VRRP 协议实现。它可以监控服务器的状态，并在服务器出现故障时自动切换到备用服务器。Keepalived 的核心功能是虚拟 IP 地址（VIP）管理。VIP 漂移确保服务的高可用性。例如，结合 Nginx 使用 Keepalived，可以实现反向代理服务器的高可用。当主 Nginx 服务器宕机时，Keepalived 会将 VIP 自动切换到备用 Nginx 服务器，保证服务的连续性。

VRRP 协议

VRRP（Virtual Router Redundancy Protocol）是一种容错协议，用于在局域网中实现网关的冗余备份。VRRP 将一组路由器（包括一个 Master 路由器和若干个 Backup 路由器）组成一个虚拟路由器，通过一个共同的虚拟 IP 地址对外提供服务。Master 路由器负责处理所有的网络请求，而 Backup 路由器则处于监听状态。当 Master 路由器出现故障时，Backup 路由器会接管 Master 路由器的职责，继续提供服务。

具体的代码/配置解决方案

1. MySQL 配置

在两台 MySQL 服务器上分别进行以下配置：

• 修改 my.cnf 文件，设置 server-id，并启用 binlog 功能。

[mysqld]
server-id=1  # 每台服务器的 ID 必须不同
log-bin=mysql-bin
binlog_format=ROW  # 推荐使用 ROW 模式，避免数据不一致
replicate-do-db=your_database # 只复制指定数据库，提高效率

• 创建用于复制的用户，并授予相应的权限。

CREATE USER 'repl'@'%' IDENTIFIED BY 'your_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

• 配置主主复制关系。在每台服务器上执行以下操作：

CHANGE MASTER TO
    MASTER_HOST='other_server_ip',
    MASTER_USER='repl',
    MASTER_PASSWORD='your_password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=4;
START SLAVE;

注意：你需要根据实际情况修改 MASTER_HOST、MASTER_USER、MASTER_PASSWORD、MASTER_LOG_FILE 和 MASTER_LOG_POS 的值。MASTER_LOG_FILE 和 MASTER_LOG_POS 可以通过 SHOW MASTER STATUS 命令获取。

2. Keepalived 配置

在两台服务器上分别安装 Keepalived，并进行以下配置：

sudo apt-get update
sudo apt-get install keepalived

• 修改 /etc/keepalived/keepalived.conf 文件，配置 VRRP 实例。

在主服务器上：

vrrp_instance VI_1 {
    state MASTER
    interface eth0  # 根据实际网卡名称修改
    virtual_router_id 51  # 所有服务器的 ID 必须相同
    priority 100  # 主服务器的优先级必须高于备用服务器
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100  # 虚拟 IP 地址
    }
    track_script {
        check_mysql
    }
}

script check_mysql {
    script "/etc/keepalived/check_mysql.sh"
    interval 2  # 检测间隔，单位为秒
    weight -20  # 权重，当检测失败时，降低优先级
}

在备用服务器上：

vrrp_instance VI_1 {
    state BACKUP
    interface eth0  # 根据实际网卡名称修改
    virtual_router_id 51  # 所有服务器的 ID 必须相同
    priority 90  # 备用服务器的优先级必须低于主服务器
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100  # 虚拟 IP 地址
    }
    track_script {
        check_mysql
    }
}

script check_mysql {
    script "/etc/keepalived/check_mysql.sh"
    interval 2  # 检测间隔，单位为秒
    weight -20  # 权重，当检测失败时，降低优先级
}

• 创建 MySQL 状态检测脚本 /etc/keepalived/check_mysql.sh。

#!/bin/bash

mysqladmin ping > /dev/null 2>&1

if [ $? -ne 0 ]; then
    exit 1
else
    exit 0
fi

确保脚本具有执行权限：

sudo chmod +x /etc/keepalived/check_mysql.sh

3. 测试验证

• 启动 Keepalived 服务：

sudo systemctl start keepalived
sudo systemctl enable keepalived

• 通过虚拟 IP 地址连接数据库，验证高可用性。断开主服务器的网络连接，观察虚拟 IP 地址是否自动切换到备用服务器。

实战避坑经验总结

• 数据一致性问题：在主主复制中，由于数据双向同步，容易出现数据冲突。需要仔细设计应用程序，避免并发修改同一数据。
• 脑裂问题：当主备服务器之间的网络出现故障时，可能导致两台服务器都认为自己是主服务器，从而产生脑裂问题。可以使用仲裁机制（例如 ZooKeeper）来解决脑裂问题。
• binlog 格式选择：推荐使用 ROW 模式的 binlog，可以避免因 SQL 语句的差异导致数据不一致。
• Keepalived 优先级设置：合理设置主备服务器的优先级，确保主服务器始终优先接管虚拟 IP 地址。
• 监控与告警：建立完善的监控与告警机制，及时发现和处理故障。
• 数据库连接池配置：在应用程序中使用数据库连接池时，需要配置连接超时时间和重试机制，以应对数据库切换时可能出现的短暂中断。

总结来说，使用 MySQL+Keepalived 实现主主复制可以显著提高数据库的可用性和容错能力。通过合理的配置和监控，可以构建一个稳定可靠的数据库集群，保障业务的连续性和数据的安全性。同时，务必注意数据一致性问题，并采取相应的措施进行解决。