【MySQL】基于位点的主从复制完整部署指南
在数据库运维中，主从复制是保障数据高可用、实现读写分离的核心方案。基于位点的复制作为 MySQL 最经典的主从部署方式，具备配置灵活、兼容性强的特点。本文将从前置准备到验证测试，一步步拆解完整部署流程，帮助运维人员快速落地。
一、基于位点的主从复制部署流程
二、前置准备（必做！）
无论采用哪种部署方式，主从复制的前置准备工作都至关重要，直接影响后续部署的成功率。核心准备工作包括Binlog 开启检查、server_id 配置和GTID 关闭三部分。
1. 确定主库 Binlog 已开启
Binlog 是 MySQL 主从复制的核心，主库通过 Binlog 记录所有数据变更操作，从库通过读取 Binlog 实现数据同步。因此，首先需要确认主库 Binlog 已开启。
（1）查看 Binlog 当前状态
登录主库 MySQL，执行以下命令查看 Binlog 是否开启：
show global variables like "log_bin";若查询结果中Value为ON，表示 Binlog 已开启；若为OFF，则需手动开启。
（2）配置文件确认（防止重启失效）
即使当前 Binlog 已开启，也需检查配置文件，确保 MySQL 重启后 Binlog 仍能正常启用。编辑主库 MySQL 配置文件：
vim /data/mysql/conf/my.cnf搜索log-bin关键字，若配置了 Binlog 路径（如log-bin=/data/mysql/binlog/mysql-bin），则说明配置有效；若未配置，需添加该配置并重启 MySQL。
2. 配置主从库唯一 server_id
server_id是 MySQL 实例在主从架构中的唯一标识，同一主从架构中所有实例的 server_id 必须不同，否则会导致复制异常。建议将server_id设置为 IP 地址的后两段（如 IP 为 192.168.184.151，可设为 184151），降低重复概率。
（1）查询当前 server_id
登录 MySQL 实例，执行以下命令查询当前server_id：
select @@global.server_id;
server_id的取值范围为 1 到 2³²-1。
（2）动态修改与配置文件持久化
- 主库配置：先动态修改
server_id（无需重启 MySQL），再修改配置文件确保重启后生效：
# 动态修改主库server_id
set global server_id=184151;
# 编辑配置文件
vim /data/mysql/conf/my.cnf
# 添加或修改server-id配置
server-id=184151- 从库配置：同理，从库需设置不同的
server_id（如 184152）：
# 动态修改从库server_id
set global server_id=1841522;
# 编辑从库配置文件
vim /data/mysql/conf/my.cnf
# 添加或修改server-id配置
server-id=1841523. 关闭 GTID（基于传统位点复制）
本文基于传统位点复制，需关闭 GTID（全局事务标识）模式。若开启 GTID，可能导致复制位点识别异常。
（1）修改主从库配置文件
分别编辑主库和从库的 MySQL 配置文件，添加或修改 GTID 相关配置：
vim /data/mysql/conf/my.cnf
# 关闭GTID模式
gtid_mode=off
# 注释或关闭GTID一致性检查
# enforce_gtid_consistency=on（2）重启 MySQL 生效
修改配置后，需重启主库和从库的 MySQL 服务：
/etc/init.d/mysql.server restart三、部署步骤（主从协同操作）
基于位点的主从复制是最经典的部署方式，核心思路是：主库导出数据并记录备份时的 Binlog 位点，从库导入主库数据后，从指定位点开始同步主库 Binlog。
1. 步骤 1：主库创建复制专用用户
从库需要通过专用用户连接主库并读取 Binlog，因此需在主库创建具备REPLICATION SLAVE权限的用户：
# 创建复制用户repl（允许所有IP访问，生产环境建议限制从库IP）
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'Uid_dQc63';
# 授予复制权限
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';2. 步骤 2：主库导出全量数据并记录位点
使用mysqldump工具导出主库全量数据，同时记录备份时的 Binlog 位点（后续从库需从该位点开始同步）。
（1）执行全量备份
# 进入备份目录（需提前创建）
cd /data/backup/
# 导出全量数据，--master_data=2表示以注释形式记录Binlog位点
mysqldump -uroot -p --single-transaction --all-databases --master_data=2 --set-gtid-purged=OFF > alldb_bak.sql命令关键参数说明：
--single-transaction：开启事务备份，确保数据一致性且不阻塞主库写操作；--all-databases：导出所有数据库（若需指定数据库，可替换为--databases 数据库名）；--set-gtid-purged=OFF：关闭 GTID 相关信息，适配传统位点复制。
（2）提取 Binlog 位点信息
备份文件alldb_bak.sql的前 30 行包含 Binlog 位点信息，执行以下命令查看：
head -n 30 alldb_bak.sql输出结果中类似如下内容即为位点信息：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000027', MASTER_LOG_POS=717;其中，MASTER_LOG_FILE为 Binlog 文件名，MASTER_LOG_POS为具体位点。
3. 步骤 3：从库导入主库全量数据
将主库的备份文件传输到从库，并导入从库，确保主从数据初始一致性。
（1）传输备份文件
通过scp命令将主库备份文件传输到从库的/data/backup目录：
# 主库执行，将备份文件传到从库（从库IP为192.168.184.152）
scp alldb_bak.sql 192.168.184.152:/data/backup（2）从库导入数据
登录从库，进入备份目录并导入数据：
cd /data/backup
# 导入主库全量数据
mysql -uroot -p < alldb_bak.sql4. 步骤 4：从库配置主从复制关系
导入数据后，需在从库配置主库信息（IP、复制用户、Binlog 位点等），并启动复制进程。
（1）配置主从关系
登录从库 MySQL，执行以下命令配置主从复制（需替换为实际主库信息和位点）：
CHANGE MASTER TO
MASTER_HOST='192.168.184.151', # 主库IP
MASTER_USER='repl', # 复制用户
MASTER_PASSWORD='Uid_dQc63', # 复制用户密码
MASTER_LOG_FILE='mysql-bin.000027', # 主库Binlog文件名（从备份中提取）
MASTER_LOG_POS=717; # 主库Binlog位点（从备份中提取）（2）启动从库复制进程
start slave;5. 步骤 5：验证主从复制状态
主从复制配置完成后，需通过SHOW SLAVE STATUS\G命令验证复制状态，核心关注以下 3 个字段：
SHOW SLAVE STATUS\G
关键状态字段说明：
Slave_IO_Running：从库 IO 线程状态，需为Yes（IO 线程负责从主库读取 Binlog 并写入中继日志）；Slave_SQL_Running：从库 SQL 线程状态，需为Yes（SQL 线程负责执行中继日志中的 SQL 语句）；Seconds_Behind_Master：从库落后主库的时间，需为0（表示主从数据实时同步）。
若上述字段均符合预期，说明基于位点的主从复制已成功部署。
6. 步骤 6：测试主从数据同步
为确保复制正常工作，可在主库执行数据写入操作，验证从库是否同步。
（1）主库创建测试表并插入数据
# 主库执行
use maria; # 切换到目标数据库（需提前存在）
create table repl_test(id int); # 创建测试表
insert into repl_test select 1; # 插入测试数据
（2）从库验证数据同步
# 从库执行
use martin;
select * from repl_test; # 若查询到id=1，说明数据同步正常
四、注意事项
配置文件修改后必须重启 MySQL，动态修改仅临时生效
生产环境中，复制用户应限制为从库 IP（替换%为具体 IP）
Binlog 文件需定期清理，避免磁盘空间溢出
若Slave_SQL_Running为No，需检查从库数据与主库一致性
同步延迟需监控，可通过Seconds_Behind_Master指标告警
