数据库主从复制学习笔记
目录
一、Binlog（Binary Log）
核心特性
核心用途
Binlog 格式（3种类型）
二、主从复制
核心原理
主库（Master）
从库（Slave）
配置步骤（以 MySQL 为例）
1. 主库配置
2. 创建复制账号
3. 从库配置
4. 启动复制
三、GTID
GTID 核心组成
GTID 核心优势
GTID 启用配置
修改 my.cnf
重启 MySQL 生效
一、Binlog（Binary Log）
Binlog（Binary Log）是 MySQL 数据库的核心日志之一，用于记录数据库的逻辑操作。简单来说，它像一台摄像机，忠实记录所有对数据库进行修改的 SQL 语句（如 INSERT/UPDATE/DELETE）或表结构变更（如 CREATE/ALTER）等操作。
核心特性
- 逻辑日志
记录的是 SQL 语句的原始逻辑（例如：UPDATE users SET age=20 WHERE id=1;），而非底层数据页的物理修改细节（这是 redo log 的特性）。
- 持久化存储
Binlog 以文件形式存储在磁盘中，不会随数据库重启而丢失，生命周期由配置决定（可长期保存）。
- 可追溯性
通过解析 binlog 文件，可以精确还原数据库的历史变更过程。
核心用途
- 主从复制（Replication）
主库将 binlog 发送给从库，从库重放这些日志以实现数据同步，是 MySQL 高可用架构的基础。
- 数据恢复
当误删数据或数据库故障时，可通过 binlog + 定期备份实现时间点恢复（Point-in-Time Recovery）。
Binlog 格式（3种类型）
| 格式 | 特点 | 示例 |
| STATEMENT | 记录原始 SQL 语句 | UPDATE orders SET create_time = NOW() WHERE status = 'unpaid'; |
| ROW | 记录每行数据的变化细节（如修改前后的整行数据 | 记录每行数据修改前后的完整值（例如：id=1 的用户 balance 从 500 → 400） |
| MIXED | 混合模式，根据 SQL 语句自动选择 STATEMENT 或 ROW 格式 | 对于 INSERT INTO payments VALUES (UUID(), 100); MIXED 模式会自动切到 ROW 格式，避免主键冲突。 |
二、主从复制
是数据库系统中实现数据高可用、读写分离、负载均衡的核心技术。其核心思想是通过将主库（Master）的数据变更异步/同步复制到从库（Slave），使从库与主库保持数据一致。
核心原理
主库（Master）
- 记录所有数据变更到 Binlog（二进制日志）
- 通过 Binlog Dump 线程 向从库发送日志事件
从库（Slave）
- I/O 线程：连接主库，接收 Binlog 并写入本地 Relay Log（中继日志）
- SQL 线程：读取 Relay Log，重放 SQL 事件，实现数据同步
配置步骤（以 MySQL 为例）
1. 主库配置
# my.cnf
[mysqld]
server_id = 1 # 唯一ID
log_bin = mysql-bin # 开启Binlog
binlog_format = ROW # 推荐ROW模式2. 创建复制账号
CREATE USER 'repl'@'%' IDENTIFIED BY 'your_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';3. 从库配置
# my.cnf
[mysqld]
server_id = 2 # 唯一ID，不能与主库冲突
relay_log = mysql-relay-bin # 开启Relay Log
read_only = ON # 从库设为只读（防误操作）4. 启动复制
-- 从库执行
CHANGE MASTER TO
MASTER_HOST = '主库IP',
MASTER_USER = 'repl',
MASTER_PASSWORD = 'your_password',
MASTER_LOG_FILE = 'mysql-bin.000001', -- 主库当前Binlog文件名
MASTER_LOG_POS = 154; -- 主库当前Binlog位置
START SLAVE; -- 启动复制三、GTID
GTID（全局事务标识符）是 MySQL 主从复制中用于唯一标识事务的机制，它解决了传统复制依赖 binlog 文件名和位置的痛点。
GTID 核心组成
每个 GTID 格式为： GTID = source_id:transaction_id
-
- source_id：产生事务的服务器唯一标识（通常是 server_uuid）
- transaction_id：事务序列号，单调递增（如 1-100 表示第1到第100个事务）
示例： 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 表示该事务来自 server_uuid 为 3E11FA47... 的服务器，事务序列号为1到5。
GTID 核心优势
| 传统复制痛点 | GTID 解决方案 |
| 主从切换需手动指定 binlog 位置 | 自动追踪事务，无需关心文件位置 |
| 难以确定事务是否在所有从库执行 | 通过 GTID 集合全局唯一标识事务状态 |
| 级联复制拓扑管理复杂 | 事务路径清晰，支持任意拓扑结构 |
GTID 启用配置
修改 my.cnf
[mysqld]
gtid_mode = ON # 启用 GTID
enforce_gtid_consistency = ON # 强制 GTID 一致性
log_bin = mysql-bin # 必须开启 binlog
server_id = 1 # 服务器唯一 ID重启 MySQL 生效
systemctl restart mysqld