MySQL 数据库主从复制配置：从传统复制到 GTID

在生产环境中数据库的高可用和负载均衡至关重要。MySQL 主从复制是实现读写分离、数据备份和故障切换的基础。本文将详细介绍两种主流的主从配置方式传统的 AB 复制与基于 GTID 的复制并附上详细的实操步骤与避坑指南。一、 核心概念与原理在开始配置前我们需要了解主从复制的基本原理。无论哪种方式都要求主库与从库安装相同版本的数据库。1. 传统主从复制AB 复制传统方式主要依赖二进制日志进行同步。核心组件Master开启log-bin二进制日志记录所有数据变更。Slave开启relay-log中继日志用于存储从主库拉取的日志。工作线程IO 线程连接主库读取 binlog 并写入本地 relay-log。SQL 线程读取 relay-log 并回放 SQL 语句。特点需要手动指定 binlog 文件名和位置配置相对繁琐切换时需人工干预位点。2. GTID 复制GTID全局事务标识为每个事务分配了唯一的 ID。核心配置需开启gtid_mode、enforce_gtid_consistency等参数。优势不再依赖手动指定文件名和位点。从库会根据已执行事务的 GTID 集合自动向主库请求缺失事务配置更简单且支持自动故障切换更适合现代高可用架构。二、传统 AB 复制搭建1. 主数据库配置步骤 1修改配置文件/etc/my.cnf确保 server-id 唯一并开启二进制日志。[mysqld] server-id10 log-binmysql-bin注意修改配置后需重启数据库服务systemctl restart mysqld。步骤 2创建复制用户创建用于复制的专用账户并授予REPLICATION SLAVE权限。针对 MySQL 8.0建议指定认证插件以绕过 SSL 握手麻烦。-- 创建用户 CREATE USER repl192.168.146.176 IDENTIFIED BY 123456; -- 指定认证方式解决 MySQL 8.0 连接问题 ALTER USER repl192.168.146.176 IDENTIFIED WITH mysql_native_password BY 123456; -- 授权 GRANT REPLICATION SLAVE ON *.* TO repl192.168.146.176; FLUSH PRIVILEGES;步骤 3查看主库状态记录下File和Position的值从库配置时需要用到。mysql show master status; ------------------------------------------------------------------------------- | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | ------------------------------------------------------------------------------- | mysql-bin.000001 | 2262 | | | | -------------------------------------------------------------------------------2. 从数据库配置步骤 1修改配置文件/etc/my.cnf设置唯一的 server-id开启中继日志并建议开启只读模式。[mysqld] server-id11 relay-logmysql-relay-bin read_only1步骤 2配置同步信息在从库中执行以下 SQL指向主库的地址、用户、密码及刚才记录的日志文件和位点。-- 停止已有复制线程如有 STOP SLAVE; RESET SLAVE ALL; -- 配置主库连接信息 CHANGE MASTER TO MASTER_HOST192.168.146.173, MASTER_USERrepl, MASTER_PASSWORD123456, MASTER_LOG_FILEmysql-bin.000001, MASTER_LOG_POS2262; -- 启动复制 START SLAVE;步骤 3验证状态查看Slave_IO_Running和Slave_SQL_Running是否均为Yes。SHOW SLAVE STATUS\G三、基于 GTID 的主从配置1. 主数据库配置步骤 1修改配置文件/etc/my.cnf在传统配置基础上增加 GTID 相关参数。[mysqld] server-id10 log-binmysql-bin # 以下是 GTID 必需的关键配置 gtid_modeON enforce_gtid_consistencyON步骤 2创建复制用户操作同传统方式略步骤 3查看主库状态此时Executed_Gtid_Set列应显示事务集合。mysql show master status; ------------------------------------------------------------------------------------------------------ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | ------------------------------------------------------------------------------------------------------ | mysql-bin.000003 | 860 | | | 1f0b4304-8a33-11f1-8fcb-000c291ea219:1-3 | ------------------------------------------------------------------------------------------------------2. 从数据库配置步骤 1修改配置文件/etc/my.cnf同样开启 GTID 模式。[mysqld] server-id11 relay-logmysql-relay-bin read_only1 # 以下是 GTID 必需的关键配置 gtid_modeON enforce_gtid_consistencyON步骤 2配置同步信息与传统方式不同这里不再需要指定MASTER_LOG_FILE和MASTER_LOG_POS而是启用MASTER_AUTO_POSITION1。-- 重置之前的同步信息如果之前配过传统复制 STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO MASTER_HOST192.168.146.173, MASTER_USERrepl, MASTER_PASSWORD123456, MASTER_AUTO_POSITION1; -- 启动并检查 START SLAVE; SHOW SLAVE STATUS\G四、 关键注意事项与避坑指南在实际搭建过程中以下几点至关重要直接影响配置的成败MySQL 8.0 认证插件问题MySQL 8.0 默认使用caching_sha2_password会强制启用 SSL 加密认证配置证书极为繁琐。最佳实践是在创建复制用户时直接指定mysql_native_password认证插件以绕开 SSL 握手问题。Server-ID 与 UUID 唯一性server-id在整个主从架构中必须唯一。数据目录下的auto.cnf文件中包含server-uuid必须全集群唯一。避坑如果你是通过虚拟机克隆搭建的从库务必删除从库数据目录下的auto.cnf文件重启数据库后会自动生成新的 UUID否则会因 UUID 冲突导致复制失败。数据一致性搭建前必须保证主从数据一致。建议先锁定主库或停止业务写入进行全量备份并导入从库然后再开启复制。网络与权限确保主从节点网络互通且防火墙放行数据库端口默认 3306。复制用户应遵循最小权限原则仅授予REPLICATION SLAVE权限严禁使用 root 用户进行复制。配置修改生效修改my.cnf配置文件后必须重启数据库服务才能生效。