MySQL 复制不是实时备份。它通过 binary log 把源库事务传到副本并重放，可用于读扩展、故障切换和备份卸载，但误删也会被复制。
## 常用检查
```sql
SELECT VERSION();
SHOW DATABASES;
SHOW PROCESSLIST;
SHOW ENGINE INNODB STATUSG
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'gtid_mode';
```
账号使用最小权限和明确来源，不使用万能 host：
```sql
CREATE USER 'app'@'10.%' IDENTIFIED BY 'USE_A_SECRET_MANAGER';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app'@'10.%';
SHOW GRANTS FOR 'app'@'10.%';
```
不要把密码写进命令行历史；使用受保护的 option file、login-path 或 Secret 系统。
## 复制链路
源库提交事务并写入 binlog。副本 I/O 线程读取事件写入 relay log，SQL/applier 线程重放。GTID 为事务提供全局身份，使副本定位和切换比文件+位置更可靠。
推荐 row-based replication，减少 statement 模式对非确定函数、触发器和库上下文的依赖。源与副本版本、字符集、SQL mode 和表结构仍需兼容。
## GTID 配置要点
源与副本需要唯一 server_id、启用 binary log、GTID 和一致性约束。新副本先通过物理备份、Clone Plugin 或一致性逻辑备份初始化，再配置复制通道。
现代语法示意：
```sql
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='db-source.example.internal',
SOURCE_USER='repl',
SOURCE_PASSWORD='FROM_SECRET_MANAGER',
SOURCE_AUTO_POSITION=1;
START REPLICA;
SHOW REPLICA STATUSG
```
生产凭证应通过 TLS 和 Secret 管理，复制账号仅授予所需权限。
## 监控复制
关注：IO/SQL 线程状态、Seconds_Behind_Source 的局限、Retrieved/Executed GTID 集合、relay log 空间、复制错误、并行 worker、网络和磁盘延迟。延迟为 0 也不代表数据已通过业务一致性校验。
发生错误时先保存状态和错误事件，确认是数据冲突、DDL、权限、版本还是网络问题。跳过事务可能造成永久不一致，只能在理解业务影响并完成校验后采用。
## 备份
小型数据库可使用 mysqldump/mysqlpump；大型 InnoDB 通常使用物理热备或 Clone。备份必须包含恢复所需的 binlog/GTID 位置、账号与配置，并定期恢复演练。
```bash
mysqldump --single-transaction --routines --events --triggers DB > backup.sql
```
不要把副本当成唯一备份：误操作和逻辑损坏会传播。至少保留独立、受控、可验证的备份副本。
## 安全切换
1. 确认候选副本已追平且数据校验通过。
2. 停止或转移源库写入。
3. 等待 GTID 应用完成。
4. 提升副本并更新连接入口。
5. 验证读写、事务、监控和备份。
6. 旧源隔离后重新构建，避免双主写入。
参考：https://dev.mysql.com/doc/refman/8.4/en/replication.html