想象你有两个保险箱，一个放原件（主库），另一个实时同步备份（从库）。MySQL 复制就是这种"实时同步备份"机制，确保数据安全和高可用！
📑 目录
- [MySQL 复制概述](#MySQL 复制概述)
- 名词解释（命令与术语）
- [MySQL 复制原理](#MySQL 复制原理)
- [MySQL 复制配置](#MySQL 复制配置)
- [MySQL 复制部署实战](#MySQL 复制部署实战)
- 复制状态监控
- 常见问题与故障排查
- 最佳实践
- [主从复制在不同 MySQL 版本上的支持与差异](#主从复制在不同 MySQL 版本上的支持与差异)
- 与其他数据库复制方案对比
- 总结
- 官方文档与参考
🎯 MySQL 复制概述
什么是 MySQL 复制？
MySQL 复制 是一种数据同步技术，将一个 MySQL 服务器（主库）的数据自动复制到一个或多个 MySQL 服务器（从库）。
官方定义简述 （来源：MySQL 8.4 Replication）：MySQL 复制允许将源（Source）服务器 上的数据变更同步到副本（Replica）服务器 。源将变更写入二进制日志（Binary Log） ，副本通过 I/O 线程拉取并写入中继日志（Relay Log） ，再由 SQL 线程在副本上重放。支持基于文件位置 或 GTID（Global Transaction Identifier） 的复制；可配置异步、半同步等。详见 Chapter 19 Replication 及 Replication Administration。
官方依据与术语说明（便于核对本文正确性）：
- 术语 ：MySQL 8.0+ 文档使用 Source（源） 与 Replica（副本） ；本文为兼容旧版仍多用主库/从库、MASTER/SLAVE，含义一致。8.0+ 中
CHANGE REPLICATION SOURCE TO、START REPLICA、SHOW REPLICA STATUS与旧语法等价。 - server_id ：官方 Replication Options 规定，复制拓扑中每台机器必须设置唯一 的 server_id，取值范围 1 到 2^32−1；若为 0，源会拒绝副本连接，副本也不会连源。
- 复制格式 ：官方 Replication Formats 规定，支持 SBR（Statement-Based）、RBR（Row-Based）、MBR（Mixed） ；MySQL 8.4 默认为 Row-Based。MySQL 8.0 起修改 binlog_format 已被弃用，未来版本将仅支持行格式。
- 同步方式 ：官方说明复制默认异步 ；另支持半同步（Semisynchronous） 、延迟复制（Delayed Replication） ；同步复制为 NDB Cluster 特性，非传统主从。
从库Slave
主库Master
写入操作
读取 Binlog
执行 SQL
读取操作
👤 应用程序
🗄️ MySQL Master
📜 二进制日志
Binlog
📥 I/O 线程
📋 中继日志
Relay Log
▶️ SQL 线程
🗄️ MySQL Slave
生活类比：
- 主库 = 原始文件存放地
- 从库 = 实时复印的副本
- Binlog = 复印记录本
- I/O 线程 = 复印操作员
- **SQL 线程 = 执行复印内容的操作员
复制的类型
| 复制类型 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 异步复制 | 主库不等从库确认 | ⭐⭐⭐⭐⭐ 性能最好 | 可能丢失数据 |
| 半同步 | 等待至少一个从库确认 | ⭐⭐⭐ 平衡性能 | 延迟增加 |
| 全同步 | 等待所有从库确认 | ⭐ 数据最安全 | ⭐ 性能最差 |
📖 名词解释（命令与术语）
以下对文档中出现的命令、配置项、概念做简要解释，并配上生活例子与「为什么」，便于记忆与理解。
常用命令
| 命令/名称 | 含义 | 说明 | 生活例子 | 为什么？ |
|---|---|---|---|---|
| CHANGE MASTER TO | 配置主从关系 | 指定主库地址、用户、密码、日志位置或 GTID | 像「登记：我要跟哪个人抄作业、从哪一页开始抄」 | 为什么 MASTER_AUTO_POSITION=1？用 GTID 后不用记 File/Position，从库自动从断点续传 |
| START SLAVE | 启动复制 | 启动 I/O 线程和 SQL 线程（8.0+ 可用 START REPLICA） | 像「开始抄作业」 | 为什么有时要 STOP 再 START？改完 CHANGE MASTER TO 或跳过错误后需重启复制 |
| SHOW SLAVE STATUS\G | 查看从库复制状态 | 显示 IO/SQL 线程状态、延迟、错误、位点等（8.0+ 可用 SHOW REPLICA STATUS） | 像「看抄到哪一页、有没有抄错」 | 为什么看 Seconds_Behind_Master？大于 0 表示有延迟，持续增大说明跟不上主库 |
| SHOW MASTER STATUS | 查看主库 Binlog 状态 | 显示当前 Binlog 文件名和位置（8.0+ 可用 SHOW BINARY LOG STATUS） | 像「看主库写到哪一页了」 | 为什么传统复制要记 File/Position？从库 CHANGE MASTER 时要指定从主库的哪个位置开始拉 |
| RESET SLAVE | 清空从库复制配置 | 删除 master.info、relay log 等，需重新 CHANGE MASTER（8.0+ RESET REPLICA） | 像「撕掉抄作业记录，重新登记」 | 为什么慎用？清空后要从头或从新位点拉，用错会丢数据或重复；GTID 下可配合重新指定主库 |
核心概念
| 名词 | 含义 | 生活例子 | 为什么？ |
|---|---|---|---|
| Binlog | 二进制日志，记录主库数据变更 | 像「主库的变更流水账」 | 为什么需要？主库靠它把变更「播」出去，从库靠它重放；也用于 PITR 恢复 |
| Relay Log | 中继日志，从库上存从主库拉来的 Binlog 副本 | 像「从库的临时抄写本」 | 为什么不在从库直接执行？先落盘再由 SQL 线程执行，主库断连时从库还能继续追一段 |
| GTID | Global Transaction Identifier，全局事务 ID | 像「每笔变更的全球唯一编号」 | 为什么推荐？换主、加从、断点续传不用记 File/Position，按事务追即可 |
| server-id | 复制拓扑中每台机器唯一 ID | 像「学号」：同一拓扑里不能重复 | 为什么必须唯一？主从用 server-id 区分是谁发的、避免循环复制 |
| binlog_format | Binlog 记录格式：ROW/STATEMENT/MIXED | ROW=记每行变化，STATEMENT=记 SQL 语句 | 为什么推荐 ROW？避免 NOW()、UUID() 等在主从执行结果不一致；STATEMENT 体积小但语义有风险 |
| read_only | 从库只读（super_read_only 更严） | 像「从库只能看、不能改」 | 为什么从库要开？防止误在从库写数据导致主从不一致；复制线程不受限 |
复制类型与 Binlog 格式对比（为什么选哪种？）
| 复制类型 | 主库何时返回 | 为什么选？ |
|---|---|---|
| 异步 | 不等从库 | 性能最好，主库故障可能丢最近几条；默认，适合对丢一点可接受的场景 |
| 半同步 | 等至少一个从库确认收到 | 主库宕机时已确认的不会丢；延迟略增，适合要兼顾性能与安全 |
| 全同步/Group Replication | 等多数或全部节点 | 强一致，延迟和复杂度高；适合金融等强一致场景 |
| binlog_format | 记录内容 | 为什么选？ |
|---|---|---|
| ROW | 每行变更前后的值 | 主从一致性好，适合推荐；体积可能较大 |
| STATEMENT | SQL 语句 | 体积小，但 NOW()、LIMIT 等可能主从结果不同 |
| MIXED | 自动选 ROW 或 STATEMENT | 折中，复杂场景仍可能不一致，一般直接用 ROW |
🏗️ MySQL 复制原理
复制三线程
从库Slave
- Binlog 2. Relay Log 🗄️ 主库 Master
📥 I/O 线程
▶️ SQL 线程
💾 从库数据目录
📋 中继日志
Relay Log
📌 复制位置
| 线程 | 英文 | 职责 | 生活类比 |
|---|---|---|---|
| Binlog Dump | 二进制日志 | 记录主库所有数据变更 | 变更记录本 |
| I/O 线程 | I/O Thread | 读取主库 Binlog | 复印员 |
| SQL 线程 | SQL Thread | 执行复制语句 | 执行复印的操作 |
复制过程详解
🗄️ 从库 ▶️ SQL 线程 📋 中继日志 📥 I/O 线程 📜 Binlog 🗄️ 主库 👤 应用程序 🗄️ 从库 ▶️ SQL 线程 📋 中继日志 📥 I/O 线程 📜 Binlog 🗄️ 主库 👤 应用程序 执行写入操作 记录到 Binlog 读取 Binlog 写入中继日志 读取中继日志 执行 SQL 语句 数据同步完成
⚙️ MySQL 复制配置
主库配置
bash
# /etc/my.cnf
[mysqld]
# 服务器 ID，同一复制拓扑内必须唯一
server-id = 1
# 启用二进制日志
log-bin = mysql-bin
log_bin_index = mysql-bin.index
# 要复制的数据库
binlog_do_db = myapp
binlog_ignore_db = mysql
# binlog 格式（推荐 row）
binlog_format = ROW
# binlog 过期时间（MySQL 5.7 及以前）
expire_logs_days = 7
# MySQL 8.0+ 推荐用 binlog_expire_logs_seconds（秒）
# binlog_expire_logs_seconds = 604800
# binlog 单文件大小
max_binlog_size = 100M
# 每次事务提交时同步 binlog 到磁盘（1=安全，0=性能）
sync_binlog = 1
# GTID 模式（MySQL 5.6+）
gtid_mode = ON
enforce_gtid_consistency = ON主库常用参数说明 （与 MySQL 8.4 Replication Options 一致）：
| 参数 | 说明 | 官方建议/默认 |
|---|---|---|
| server_id | 复制拓扑内唯一，1～2^32−1 | 必设；0 则拒绝复制连接 |
| log_bin | 启用二进制日志 | 主库必开 |
| binlog_format | ROW / STATEMENT / MIXED | 8.4 默认 ROW；8.0 起改格式已弃用 |
| binlog_expire_logs_seconds | binlog 保留秒数（8.0+） | 替代 expire_logs_days |
| sync_binlog | 每次提交是否 fsync binlog | 1 更安全，0 性能更好 |
| gtid_mode | 是否启用 GTID | ON 时需配合 enforce_gtid_consistency=ON |
| enforce_gtid_consistency | 保证事务可被 GTID 安全复制 | 启用 GTID 时建议 ON |
从库配置
bash
# /etc/my.cnf
[mysqld]
# 服务器 ID，必须唯一且不同于主库
server-id = 2
# 中继日志
relay-log = relay-bin
relay-log-index = relay-bin.index
# 启用只读模式（可选，推荐）
read_only = 1
# 跳过错误（可选，谨慎使用）
# slave_skip_errors = all
# slave_skip_errors = 1062
# GTID 模式（与主库一致）
gtid_mode = ON
enforce_gtid_consistency = ON
# 并行复制（MySQL 5.6+，从库多线程应用）
replica_parallel_workers = 4
# MySQL 5.7 及以前变量名：slave_parallel_workers
# 从库崩溃恢复时从 relay log 重新拉取（建议开启）
relay_log_recovery = 1
# 只复制指定库/表（可选）
# replicate_do_db = myapp
# replicate_ignore_db = mysql
# replicate_do_table = myapp.orders
# replicate_ignore_table = myapp.logs从库常用参数说明 （与 Replica Options 一致）：
| 参数 | 说明 | 官方建议/默认 |
|---|---|---|
| server_id | 与主库及其他从库均不同 | 必设 |
| relay_log | 中继日志文件名前缀 | 建议显式设置便于排查 |
| read_only | 禁止普通用户写 | 从库建议 1；复制线程不受限 |
| super_read_only | 禁止包括 SUPER 的写（8.0+） | 需严格只读时与 read_only 同开 |
| relay_log_recovery | 崩溃后是否从主库重新拉取 relay | 建议 1，避免 relay 损坏导致数据不一致 |
| replica_parallel_workers | 并行应用 relay 的线程数（8.0+） | 可设为 4～8 降低延迟；旧版为 slave_parallel_workers |
| replicate_do_db / replicate_ignore_db | 库级过滤 | 按需设置；过滤不当易导致主从不一致 |
半同步复制配置（可选）
半同步要求主库在提交时至少等待一个从库确认收到事件后再返回，可减少主库宕机时的数据丢失。需主从均安装半同步插件（MySQL 8.0+ 变量名以 source/replica 为主）：
bash
# 主库 my.cnf 或运行时设置
[mysqld]
# 加载半同步插件（通常已内置，需 INSTALL PLUGIN 或配置 plugin-load）
# 启用半同步
rpl_semi_sync_source_enabled = 1
# 等待从库确认的超时（毫秒），超时后退化为异步
rpl_semi_sync_source_timeout = 10000
# 至少几个从库确认后才返回（多从库时）
rpl_semi_sync_source_wait_for_replica_count = 1
# 从库
[mysqld]
rpl_semi_sync_replica_enabled = 1说明 ：变量名在 MySQL 8.0+ 为 rpl_semi_sync_source_* / rpl_semi_sync_replica_*；5.7 及以前为 rpl_semi_sync_master_* / rpl_semi_sync_slave_*。详见 Semisynchronous Replication。
延迟复制配置（可选）
从库可故意落后主库一段时间（如 1 小时），便于误操作后在从库找回数据：
sql
-- 在从库执行（MySQL 8.0+ 语法）
STOP REPLICA;
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='192.168.1.10',
SOURCE_USER='repl',
SOURCE_PASSWORD='ReplPass123!',
SOURCE_AUTO_POSITION=1,
SOURCE_DELAY = 3600; -- 延迟 3600 秒（1 小时）
START REPLICA;传统语法示例：CHANGE MASTER TO ... MASTER_DELAY = 3600;。详见 Delayed Replication。
创建复制用户
sql
-- 在主库上执行
-- 创建复制用户
CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'StrongPassword123!';
-- 授权复制权限
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
-- 刷新权限
FLUSH PRIVILEGES;
-- 查看主库状态
SHOW MASTER STATUS;
-- 或 MySQL 8.0+
SHOW BINARY LOG STATUS;🚀 MySQL 复制部署实战
环境准备
📋 环境准备
🖥️ 主库: 192.168.1.10
🖥️ 从库: 192.168.1.11
📦 安装 MySQL 8.0
完整部署步骤
1. 主库操作
bash
# 1. 配置主库
cat >> /etc/my.cnf << 'EOF'
[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
gtid_mode=ON
EOF
# 2. 重启 MySQL
systemctl restart mysqld
# 3. 创建复制用户
mysql -u root -p << EOF
CREATE USER 'repl'@'%' IDENTIFIED BY 'ReplPass123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
EOF
# 4. 查看主库状态
mysql -u root -p -e "SHOW MASTER STATUS;"
# 记录 File 和 Position2. 从库操作
bash
# 1. 配置从库
cat >> /etc/my.cnf << 'EOF'
[mysqld]
server-id=2
relay-log=relay-bin
read_only=1
gtid_mode=ON
EOF
# 2. 重启 MySQL
systemctl restart mysqld
# 3. 配置复制
mysql -u root -p << EOF
CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl',
MASTER_PASSWORD='ReplPass123!',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
-- 或使用 GTID（推荐）
CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl',
MASTER_PASSWORD='ReplPass123!',
MASTER_AUTO_POSITION=1;
START SLAVE;
EOF
# 4. 查看复制状态
mysql -u root -p -e "SHOW SLAVE STATUS\G"3. 验证复制
bash
# 在主库创建测试数据
mysql -u root -p -e "CREATE DATABASE testdb; USE testdb; CREATE TABLE test (id INT); INSERT INTO test VALUES (1);"
# 在从库查看
mysql -u root -p -e "SELECT * FROM testdb.test;"
# 应该能看到相同的数据📊 复制状态监控
监控命令
sql
-- 查看从库状态
SHOW SLAVE STATUS\G
-- 关键指标：
-- Slave_IO_State: I/O 线程状态（应该是 Yes）
-- Slave_SQL_Running: SQL 线程状态（应该是 Yes）
-- Seconds_Behind_Master: 延迟秒数（越小越好）
-- Seconds_Behind_Source: GTID 延迟（GTID 模式）
-- 查看 GTID 执行状态
SHOW PROCESSLIST;
-- 查看复制延迟
-- 主库
SHOW MASTER STATUS;常见状态值
| 状态 | 说明 | 期望值 |
|---|---|---|
| Slave_IO_State | I/O 线程状态 | Connecting / Yes |
| Slave_SQL_Running | SQL 线程状态 | Yes |
| Last_IO_Errno | I/O 错误码 | 0 |
| Last_SQL_Errno | SQL 错误码 | 0 |
⚠️ 常见问题与故障排查
复制延迟
⚠️ 复制延迟高
🌐 网络问题?
📈 主库负载高?
🖥️ 从库配置低?
优化网络
主库优化
从库升级
解决步骤：
sql
-- 1. 检查从库状态
SHOW SLAVE STATUS\G
-- 2. 查看 Seconds_Behind_Master
-- 如果持续增长，说明复制延迟
-- 3. 跳过错误（谨慎使用）
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
-- 4. 重置复制（最后手段）
STOP SLAVE;
RESET SLAVE;
-- 重新配置 CHANGE MASTER TO复制中断
bash
# 1. 检查复制用户权限
mysql -u repl -p -h 192.168.1.10
# 2. 检查网络连通性
ping -c 3 192.168.1.10
telnet 192.168.1.10 3306
# 3. 检查主库 Binlog
mysql -u root -p -h 192.168.1.10 -e "SHOW MASTER STATUS;"
# 4. 重启复制
mysql -u root -p
STOP SLAVE;
START SLAVE;💡 最佳实践
配置建议
- 使用 GTID 模式 ：MySQL 5.6+ 推荐
为什么？ 换主、加从、断点续传不用记 File/Position，按事务 ID 即可；主从切换更简单。 - row 格式 Binlog ：更安全可靠
为什么？ 记录行级变更，主从结果一致；STATEMENT 下 NOW()、UUID()、LIMIT 等可能主从不一致。 - 从库只读 ：read_only=1（建议 super_read_only=1）
为什么？ 防止误在从库写数据导致主从不一致；复制线程不受 read_only 限制。 - 监控延迟 ：Seconds_Behind_Master / 复制位点
为什么？ 延迟大时从库读到的数据陈旧，读写分离场景会影响业务；持续增大说明从库跟不上。 - 定期备份 ：复制不是备份
为什么？ 误删表、DROP DATABASE 会同步到从库；备份可做 PITR、防误删。
复制 vs 备份
🛡️ 数据保护
🔄 复制
💾 备份
实时同步
故障转移
读写分离
定期快照
误删恢复
| 特性 | 复制 | 备份 |
|---|---|---|
| 实时性 | 实时同步 | 定期备份 |
| 目的 | 高可用、读写分离 | 灾难恢复 |
| 历史版本 | 无 | 有 |
| 防误删 | ❌ 无效 | ✅ 有效 |
| 生活类比 | 实时复印机 | 定期归档 |
📌 主从复制在不同 MySQL 版本上的支持与差异
不同 MySQL 大版本对主从复制的功能支持 和默认行为 有差异，本节从版本支持周期、复制相关特性、混版本主从注意点三方面做简要分析，便于选型与升级时参考。官方支持状态以 MySQL Product Support EOL 为准。
版本与支持周期概览
| 版本 | 发布/重要节点 | 支持状态（截至文档编写时） | 说明 |
|---|---|---|---|
| 5.5 | 2010 GA | 已进入 Lifetime Sustaining Support（约 2018 年底起） | 仅安全/缺陷修复，无新功能；新项目不推荐 |
| 5.6 | 2013 GA | 已进入 Lifetime Sustaining Support（2021 年 2 月起） | 引入 GTID、多线程从库、延迟复制等；新项目不推荐 |
| 5.7 | 2015 GA | 已进入 Lifetime Sustaining Support（2023 年 10 月起） | 并行复制增强、多源复制、Group Replication；存量仍常见 |
| 8.0 | 2018 GA，LTS | 主流支持至约 2025 ，扩展支持至约 2026 年 4 月 | 推荐新项目与升级目标；Source/Replica 语法、默认 ROW |
| 8.4 | 2024 GA，LTS | 长期支持（支持周期更长） | 当前推荐 LTS 之一，与 8.0 复制兼容性好 |
| 9.x | Innovation 系列 | 按创新版生命周期 | 新特性多，复制行为以对应版本文档为准 |
说明 ：Sustaining Support 表示仅缺陷修复与安全补丁，不再提供功能增强。新上主从复制建议使用 8.0 或 8.4 LTS。
复制相关特性按版本支持度
下表汇总主从复制 相关特性在各版本的首次出现 或重要变更，便于判断当前版本能用到哪些能力。
| 特性 | 5.5 | 5.6 | 5.7 | 8.0 | 8.4+ | 备注 |
|---|---|---|---|---|---|---|
| 基础主从（Binlog + 位点） | ✅ | ✅ | ✅ | ✅ | ✅ | 所有版本均支持 |
| 半同步复制 | ✅ 引入 | ✅ | ✅ | ✅ | ✅ | 5.5 引入；8.0 起变量名改为 rpl_semi_sync_source_* / replica_* |
| GTID | ❌ | ✅ 引入 | ✅ | ✅ | ✅ | 5.6 引入；换主、加从、断点续传更简单，推荐开启 |
| 从库多线程复制 | ❌ | ✅ 引入（按库并行） | ✅ 增强（LOGICAL_CLOCK） | ✅ | ✅ | 5.6：slave_parallel_workers、按 DATABASE；5.7：可按逻辑时钟并行 |
| 延迟复制 | ❌ | ✅ 引入 | ✅ | ✅ | ✅ | MASTER_DELAY / SOURCE_DELAY |
| 多源复制（一从对多主） | ❌ | ❌ | ✅ 引入 | ✅ | ✅ | 基于 channel，多主写入同一从库 |
| Group Replication | ❌ | ❌ | ✅ 引入 | ✅ | ✅ | 多主/单主组复制，需 3 节点起，本文不展开 |
| CHANGE REPLICATION SOURCE TO / START REPLICA 等 | ❌ | ❌ | ❌ | ✅ 引入 | ✅ | 与 MASTER/SLAVE 等价，旧语法 8.0 仍可用但标记弃用 |
| replica_parallel_workers | ❌ | ❌ | ❌ | ✅ 引入 | ✅ | 替代 slave_parallel_workers，旧变量名仍可用 |
| Binlog 默认 ROW | ❌ 默认 SBR | ❌ | ❌ | ✅ 默认 ROW | ✅ | 8.0 起修改 binlog_format 已弃用，未来仅支持 ROW |
| binlog_expire_logs_seconds | ❌ | ❌ | ❌ | ✅ 引入 | ✅ | 替代 expire_logs_days（秒级精度） |
小结 ：若需要 GTID + 并行从库 + 半同步 ，至少需 5.6 （建议 5.7 及以上）；若希望与当前文档和官方手册一致（Source/Replica、默认 ROW、新参数），建议 8.0 或 8.4。
混版本主从的注意点
- 主库版本 ≥ 从库版本：官方推荐主库不低于从库，避免主库产生从库无法识别的 Binlog 事件或语法。
- 5.7 主 → 8.0 从：可行，但 8.0 从库需兼容 5.7 的 Binlog格式（如 ROW/STATEMENT）；建议先在从库侧测试再上线。
- 8.0 主 → 5.7 从：不推荐；8.0 默认 ROW 且可能有新事件类型，5.7 可能无法正确解析。
- 变量名与语法 ：5.7 及以前用
slave_*、rpl_semi_sync_master_*/rpl_semi_sync_slave_*、CHANGE MASTER TO、SHOW SLAVE STATUS；8.0+ 推荐replica_*、rpl_semi_sync_source_*/rpl_semi_sync_replica_*、CHANGE REPLICATION SOURCE TO、SHOW REPLICA STATUS。脚本与监控需按实际版本选择。 - 认证与密码插件：8.0 默认使用 caching_sha2_password，5.7 从库连接 8.0 主库时可能需在主库将复制用户设为 mysql_native_password，或从库安装相应插件。
选型与升级建议（主从复制视角）
| 场景 | 建议 |
|---|---|
| 新项目 | 使用 8.0 或 8.4 LTS，开启 GTID、ROW、半同步（按需）、从库只读与延迟监控。 |
| 存量 5.6/5.7 | 规划升级到 8.0/8.4；升级前确认 GTID、并行复制、半同步在现网已稳定使用，便于迁移后行为一致。 |
| 仍在使用 5.5 | 仅能使用基础主从 + 半同步，无 GTID、无并行从库；强烈建议在支持周期内升级。 |
| 多源复制 | 需 5.7 或 8.0+，从库多 channel 对接多个主库。 |
| Group Replication / InnoDB Cluster | 需 5.7 或 8.0+，与本文传统主从为不同架构，按官方文档单独规划。 |
以上支持度与建议基于 MySQL 官方文档与 EOL 公告整理，具体以 MySQL Reference Manual 及 EOL Notice 为准。
🔀 与其他数据库复制方案对比
了解 Oracle、PostgreSQL、SQL Server 等数据库的复制/高可用方案，有助于在技术选型或迁移时做对比。下表从术语、数据同步机制、副本类型、同步方式、故障转移等维度与 MySQL 主从复制做简要对比（MySQL 以本文所述的传统主从 + 半同步为参照）。
对比总览
| 维度 | MySQL 主从复制 | Oracle Data Guard | PostgreSQL 流复制 | SQL Server Always On |
|---|---|---|---|---|
| 术语 | Source/Replica（主库/从库） | Primary / Standby | Primary / Standby | Primary / Secondary |
| 同步载体 | Binlog（二进制日志） | Redo（重做日志/归档） | WAL（Write-Ahead Log） | 事务日志 |
| 副本形态 | 逻辑副本（重放 SQL/行事件） | Physical Standby（块级）/ Logical Standby（SQL Apply） | 物理副本（字节级镜像）为主；逻辑复制可选 | 可用性组内副本（数据库级） |
| 副本数量 | 无硬性上限 | 最多 30 个目标 | 通常多个 standby | 1 个主 + 最多 8 个次要副本 |
| 默认同步方式 | 异步 | Maximum Performance（异步） | 异步 | 可配同步/异步 |
| 零/少丢失 | 半同步插件 | Maximum Protection / Maximum Availability | 同步复制（synchronous_commit） | 同步提交模式 |
| 故障转移 | 多为手动或借助 MHA/Orchestrator 等 | Broker 支持自动 Fast-Start Failover | 手动 promote 或 + Patroni 等 | 内置自动/手动故障转移 |
| 从库读 | ✅ 支持，常用于读写分离 | Physical：只读；Logical：可读写（SQL Apply） | ✅ Standby 可只读查询 | ✅ 可配置只读路由 |
Oracle Data Guard 简要对比
Oracle Data Guard 是 Oracle 官方的高可用与灾备方案，与 MySQL 主从复制的对比如下：
- 数据同步 ：主库把 Redo 传到备库；备库用 Redo Apply （物理备库，块级一致）或 SQL Apply（逻辑备库，转成 SQL 执行）。MySQL 则是传 Binlog，从库用 I/O + SQL 线程重放事件。
- 副本类型 ：Oracle 有 Physical Standby （与主库块级一致、可只读）、Logical Standby （可打开读写，用 SQL Apply 同步）、Snapshot Standby（临时可写快照）。MySQL 从库一般为只读逻辑副本。
- 保护模式 ：Oracle 提供 Maximum Protection （零数据丢失，主库写不到备库会停）、Maximum Availability （尽量零丢失，否则降级）、Maximum Performance（默认，异步，类似 MySQL 默认）。MySQL 需通过半同步接近"少丢失"。
- 管理与故障转移 ：通过 Data Guard Broker （DGMGRL/EM）可做 Switchover/Failover 及 Fast-Start Failover。MySQL 传统主从通常需自行或借助 MHA/Orchestrator 等做主从切换。
- 规模 ：单主最多 30 个 standby 目标；MySQL 从库数量无官方硬性上限。
PostgreSQL 流复制简要对比
- 同步机制 ：通过 WAL 流式传输 到 Standby，Standby 持续做恢复（recovery），相当于整库的物理副本（字节级一致）。MySQL 是逻辑复制（Binlog 事件重放），从库与主库文件布局可不同。
- 模式 ：支持 同步 （synchronous_commit）与 异步 ；可配置
synchronous_standby_names指定要等待的 standby。MySQL 对应为半同步插件。 - 逻辑复制 ：PostgreSQL 另提供逻辑复制（表/库级、可跨版本），与 MySQL 的 Binlog 逻辑复制在"选择性复制"上更接近。
- 故障转移 ：通常对 Standby 执行 promote 升主；自动故障转移多依赖 Patroni、repmgr 等工具。MySQL 则依赖 MHA、Orchestrator 或自研脚本。
SQL Server Always On 简要对比
- 形态 ：Always On 可用性组（Availability Group） 以"数据库"为单位复制，一个主副本 + 最多 8 个次要副本，与 MySQL 的"实例级"主从不同。
- 同步方式 ：支持同步提交 （无数据丢失）与异步提交，可在可用性组里按副本配置。MySQL 需半同步达到类似效果。
- 故障转移 ：内置自动故障转移或手动故障转移，与 Oracle Broker 类似；MySQL 标准主从无内置自动切换。
- 读负载 ：可配置只读路由，将只读请求发到次要副本，类似 MySQL 读写分离。
参考：Always On 可用性组概述。
小结（为什么了解这些有用？）
- 选型：Oracle/PostgreSQL/SQL Server 的"主备"多为企业级内置方案，带管理界面或 Broker；MySQL 传统主从更轻量，自动故障转移多依赖生态工具。
- 迁移：从 Oracle 迁 MySQL 或反向，需理解 Redo vs Binlog、Physical vs 逻辑副本的差异，以便设计等价的 HA 与 RPO/RTO。
- 术语：主库/从库、Primary/Standby、Source/Replica 在不同产品中含义相近，对照表格便于阅读各厂商文档。
🎯 总结
MySQL 主从复制是实现高可用和读写分离的基础技术，掌握它对构建可靠的数据库架构至关重要。
核心要点记忆口诀：
- 复制三线程，IO 读 Binlog，SQL 执行语句
- 主库写变更，从库自动同步
- 复制有延迟，延迟太长要排查
- 从库可只读，分担查询压力
- 复制非备份，定期备份不能忘
生活类比总结：
- 主库 = 原件文件存储地
- 从库 = 实时同步的副本
- Binlog = 变更记录本
- I/O 线程 = 复印员
- SQL 线程 = 执行复印的操作员
最后提醒：复制能防止硬件故障，但防不了人为错误（误删表、DROP DATABASE）！
📚 官方文档与参考
本文内容已对照 MySQL 8.4 Reference Manual 核对，关键结论（server_id、复制格式、异步/半同步、GTID、Source/Replica 术语）与官方一致。以下为可直接用于核对的官方链接。
| 资源 | 链接 | 用途 |
|---|---|---|
| Chapter 19 Replication | Replication | 复制概述、Source/Replica、异步与半同步、延迟复制 |
| Replication Options | 19.1.6 Replication and Binary Logging | server_id、server_uuid 等；主从必读 |
| Source 选项 | Replication Source Options | 主库半同步等变量 |
| Replication Formats | 19.2.1 Replication Formats | SBR/RBR/MBR、binlog_format，官方默认 ROW |
| 基于位点配置 | Setting Up Replication | 传统 File/Position 配置步骤 |
| 复制管理 | Replication Administration | 查看状态、跳过错误、切换主从 |
| 半同步 | Semisynchronous Replication | rpl_semi_sync_source_* / replica_* |
| 延迟复制 | Delayed Replication | SOURCE_DELAY / MASTER_DELAY |
| 本仓库 | HA 高可用、DRBD、Keepalived | 主从 + VIP、存储复制、Director HA |
MySQL 8.0+ 与旧版语法对照（便于查官方手册）
| 含义 | 旧语法（5.7 及以前） | MySQL 8.0+ 推荐语法 |
|---|---|---|
| 配置主库连接 | CHANGE MASTER TO ... | CHANGE REPLICATION SOURCE TO ... |
| 启动复制 | START SLAVE | START REPLICA |
| 停止复制 | STOP SLAVE | STOP REPLICA |
| 查看从库状态 | SHOW SLAVE STATUS\G | SHOW REPLICA STATUS\G |
| 查看主库状态 | SHOW MASTER STATUS | SHOW BINARY LOG STATUS |
| 重置从库复制 | RESET SLAVE | RESET REPLICA |
| 半同步变量 | rpl_semi_sync_master_* / rpl_semi_sync_slave_* | rpl_semi_sync_source_* / rpl_semi_sync_replica_* |
| 并行复制变量 | slave_parallel_workers | replica_parallel_workers |
官方文档中 8.0+ 以 Source/Replica 为主，旧语法多数仍可用但标记为 deprecated。