🌟 为什么要做主从分库？
想象一下：你的电商网站突然爆单，每秒涌入上千个查询请求，数据库CPU直接飙到100%！
单库的痛点：
- 性能瓶颈：所有读写压力集中在单库，容易宕机。
- 数据风险：一旦硬盘损坏，所有数据灰飞烟灭。
- 维护困难：备份或升级时需停服，用户体验暴跌。
主从分库的优势：
- 读写分离：主库负责写，从库负责读，性能翻倍！
- 数据备份：从库实时同步数据，主库挂了也不怕。
- 无缝升级：从库先升级测试，再切主库，服务0中断。
🔧 手把手搭建主从分库
环境准备
- 主库：IP
192.168.1.100，MySQL 8.0 - 从库：IP
192.168.1.101，MySQL 8.0 - 目标数据库：
order_db
第一步：主库配置
1. 修改主库配置文件
# 编辑 my.cnf
vim /etc/my.cnf
# 添加以下配置
[mysqld]
server-id = 1 # 主库唯一ID
log-bin = mysql-bin # 开启二进制日志（关键！）
binlog-format = ROW # 推荐使用ROW格式
binlog-do-db = order_db # 仅同步order_db数据库
2. 重启MySQL并创建同步账号
-- 重启MySQL
sudo systemctl restart mysqld
-- 创建用于同步的账号
CREATE USER 'repl'@'192.168.1.101' IDENTIFIED BY 'Repl@1234';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.101';
FLUSH PRIVILEGES;
3. 查看主库状态
SHOW MASTER STATUS;
输出结果：
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 742 | order_db | |
+------------------+----------+--------------+------------------+
记住 File 和 Position，从库配置要用！
第二步：从库配置
1. 修改从库配置文件
# 编辑 my.cnf
vim /etc/my.cnf
# 添加以下配置
[mysqld]
server-id = 2 # 从库唯一ID（必须不同！）
relay-log = mysql-relay-bin # 开启中继日志
read-only = 1 # 从库设为只读（防误操作）
2. 重启MySQL并配置主库信息
-- 重启MySQL
sudo systemctl restart mysqld
-- 告诉从库主库在哪里
CHANGE MASTER TO
MASTER_HOST = '192.168.1.100',
MASTER_USER = 'repl',
MASTER_PASSWORD = 'Repl@1234',
MASTER_LOG_FILE = 'mysql-bin.000001', -- 主库的File
MASTER_LOG_POS = 742; -- 主库的Position
-- 启动同步
START SLAVE;
3. 检查从库状态
SHOW SLAVE STATUS \G
关键指标：
Slave_IO_Running: Yes -- IO线程正常
Slave_SQL_Running: Yes -- SQL线程正常
Seconds_Behind_Master: 0 -- 同步无延迟
出现以上结果，恭喜你，主从搭建成功！ ✅
🔄 数据同步原理揭秘
1. 写入主库
- 客户端向主库写入数据（如新增订单）。
- 主库将操作记录到二进制日志（Binary Log）。
2. 日志传输
- 从库的IO线程连接主库，拉取二进制日志。
- 日志保存到从库的中继日志（Relay Log）。
3. 日志重放
- 从库的SQL线程读取中继日志，执行相同的SQL操作。
- 数据最终写入从库，实现同步。
🚨 常见问题与解决方案
| 问题 | 可能原因 | 解决方案 |
|---|---|---|
| Slave_IO_Running: No | 网络不通/账号权限错误 | 检查防火墙、主从账号权限 |
| Slave_SQL_Running: No | 主从数据不一致 | 重建同步：STOP SLAVE; RESET SLAVE; 后重新配置 |
| 同步延迟大 | 从库性能不足 | 优化从库硬件或减少读请求 |
⚡ 性能优化技巧
-
半同步复制
确保主库写入后，至少一个从库确认收到日志。-- 主库执行 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; SET GLOBAL rpl_semi_sync_master_enabled = 1; -
并行复制
从库多线程重放日志，提速50%！# 从库 my.cnf slave_parallel_workers = 4 slave_parallel_type = LOGICAL_CLOCK -
GTID模式
用全局事务ID简化故障切换。# 主从库 my.cnf gtid_mode = ON enforce_gtid_consistency = ON
🌟 All Suggestion
通过主从分库，你的数据库完成了从“单兵作战”到“集团军”的蜕变！
核心价值：
- 高可用：主库故障时，从库秒级切换成新主库。
- 高性能：读写分离，轻松应对高并发。
- 数据安全：天然备份，再也不怕删库跑路！
下一步行动：
- 用
SHOW SLAVE STATUS定期监控同步状态。 - 实战演练主库故障切换，确保万无一失！
