主从复制：

MySQL 的主从复制（Replication）是其最核心的高频特性，主要用于读写分离、数据备份和负载均衡。其默认模式是异步复制。

1. 核心原理（三步曲）

MySQL 主从复制基于日志（binlog）重放机制，流程如下：

• 记录（Master）：主库执行完事务后，将数据变更按顺序写入二进制日志（Binary Log）。

• 传输（I/O Thread）：从库的 I/O 线程连接主库，读取 binlog，并写入本地的中继日志（Relay Log）。

• 重放（SQL Thread）：从库的 SQL 线程读取 Relay Log，解析成具体的 SQL 语句或行变更，在从库上重新执行。

2. 常见的复制类型

• 基于语句（Statement-Based）：记录执行的 SQL 语句。日志量小，但某些函数（如 NOW(), UUID()）可能导致主从数据不一致。

• 基于行（Row-Based）：记录每一行数据具体变更了什么（默认模式）。数据最严谨，但批量更新时日志量会变大。

• 混合（Mixed）：混合使用前两种，由 MySQL 自动判断。

3. 关键注意事项

• 主从延迟：由于是异步的，在高并发写或大事务时，从库会有延迟（Seconds_Behind_Master > 0）。这可能导致“刚写入主库，立刻读从库读不到”的问题，需在业务层做兼容（如强制读主、引入缓存）。

• 数据丢失风险：异步模式下若 Master 宕机且未同步的数据未发送到 Slave，切换到 Slave 时这部分数据会丢失。若要求强一致，需使用半同步复制（Semi-Sync）或组复制（MGR）。

• 从库只读：通常配置 read_only=1，防止应用误写入从库导致主从不一致。

mysql的主从复制实现：

修改配置文件 (my.cnf/my.ini)

[mysqld]
server-id = 1               # 集群内必须唯一
log-bin = mysql-bin         # 开启二进制日志，并指定前缀
binlog_format = ROW         # 推荐使用 ROW 模式

Mysql下：

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

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS; 
-- 记录输出中的 File (如 mysql-bin.000001) 和 Position (如 154)

从库：

[mysqld]
server-id = 2               # 必须与主库不同
relay-log = relay-bin       # 开启中继日志
read_only = 1               # 可选：设置为只读，防止误操作

Mysql下：

CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001', -- 刚才记录的 File
MASTER_LOG_POS=154;                 -- 刚才记录的 Position

启动复制：

START SLAVE;

SHOW SLAVE STATUS\G （核心检查命令）

Slave_IO_Running: Yes （I/O 线程是否正常从主库拉取日志）

Slave_SQL_Running: Yes （SQL 线程是否正常重放日志）

若无延迟，Seconds_Behind_Master应为 0。

如果IO错误：

1.主库连接失败（最常见）

网络不通：从库无法访问主库 IP / 端口（3306）

防火墙拦截

主库未监听对外地址

2.账户问题

SELECT user, host FROM mysql.user WHERE user='repl';
SHOW GRANTS FOR 'repl'@'%';

3.server id UUID冲突（特别是克隆的情况）
改配置，
删除从库 auto.cnf，重启 MySQL 自动生成新 UUID

4.SSL连接问题

如果SQL问题：可能

1.数据冲突：

库：未在从库设置只读：read_only = 1
super_read_only = 1

2.主库 binlog 格式不兼容

binlog_format = ROW