mysql主从复制通过binlog实现：主库记录写操作到binlog，从库i/o线程拉取并写入relay log，sql线程执行其中事件以保持数据一致；配置需确保主库开启binlog、设置唯一server-id、创建复制用户，从库配置唯一server-id、执行change replication source指定主库信息并start replica启动复制。

MySQL 主从复制是通过二进制日志（binlog）实现的：主库将所有写操作记录到 binlog，从库的 I/O 线程读取这些日志并写入自己的中继日志（relay log），SQL 线程再依次执行 relay log 中的事件，从而保持数据一致。配置本身不复杂，但关键在于权限、日志开启、位点对齐和网络连通性。

主库配置：开启 binlog 并创建复制用户

主库必须启用二进制日志，并设置唯一 server-id。编辑 my.cnf（或 my.ini）：

• 确保 log-bin = mysql-bin 已启用（不能是注释状态）
• 设置 server-id = 1（整数，全局唯一）
• 可选但推荐：添加 binlog-format = ROW（更安全，支持多数 DDL/DML）
• 重启 MySQL 或执行 SET PERSIST log_bin = ON;（8.0.22+ 支持动态启用）

接着创建专用复制账号（最小权限原则）：

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

从库配置：指定主库信息并启动复制

从库也要配置唯一 server-id（如 server-id = 2），无需开 binlog（除非要级联复制）。关键步骤是获取主库当前 binlog 位置并建立连接：

Java Maven Secondary Analysis

分析ZIP压缩包或GitLab仓库中的Java Maven项目，确定二次开发范围、类数量、模块分布及生产相关指标。

下载

• 在主库执行 SHOW MASTER STATUS;，记下 File 和 Position（例如 mysql-bin.000003, 154）
• 若从库是全新实例，可跳过备份；若已有数据，需先用 mysqldump --master-data=2 或 xtrabackup 获取一致快照，并导入从库
• 在从库执行：
  CHANGE REPLICATION SOURCE TO
    SOURCE_HOST='主库IP',
    SOURCE_USER='repl',
    SOURCE_PASSWORD='StrongPass123!',
    SOURCE_LOG_FILE='mysql-bin.000003',
    SOURCE_LOG_POS=154;
• 启动复制：START REPLICA;（MySQL 8.0.22+ 语法；旧版用 START SLAVE;）

验证与常见问题排查

运行 SHOW REPLICA STATUS\G（或 SHOW SLAVE STATUS\G），重点关注：

• Replica_IO_Running 和 Replica_SQL_Running 都为 Yes
• Seconds_Behind_Master 接近 0（允许短暂延迟）
• Source_IO_State 显示 Waiting for master to send event

若出错，常见原因包括：

• 网络不通或防火墙拦截 3306 端口
• 复制用户无权限或密码错误（检查 Last_IO_Error）
• 从库已存在同名表且结构/数据冲突（尤其跳过 GTID 或手工改表后）
• 主库 binlog 被清理（expire_logs_days 过小），导致从库找不到指定日志文件

进阶建议：提升稳定性与可观测性

生产环境建议补充以下配置：

• 主库设置 sync_binlog = 1 和 innodb_flush_log_at_trx_commit = 1，增强数据持久性
• 从库启用 read_only = ON（防止误写），并用 super_read_only = ON（8.0+）锁定超级用户写入
• 监控 Seconds_Behind_Master 指标，结合 pt-heartbeat 或自建心跳表检测真实延迟
• 考虑启用 GTID（gtid_mode = ON），简化故障切换和位点管理