业务做大后,单台数据库开始扛不住,或者你担心数据库一挂全站瘫痪——主从复制和读写分离就是解法。它们是数据库高可用和扩展的基础架构。本文讲清原理、作用和实现思路,帮你判断什么时候该上、怎么上。
一、什么是主从复制?
主从复制是让一台主库(Master)的数据自动同步到一台或多台从库(Slave)。主库负责写入,数据变更实时(准实时)复制到从库,从库保持和主库一致的数据副本。这是几乎所有数据库高可用方案的基础。
二、主从能解决什么问题?
- 高可用/容灾:主库挂了,从库有完整数据副本,可切换顶上,数据不丢、业务能恢复;
- 读扩展(读写分离):把大量的读请求分给从库,主库专注写,分摊压力——这是应对读多写少业务的利器;
- 备份不影响主库:在从库上做备份,不占用主库性能;
- 数据分析:在从库跑重查询和报表,不影响线上业务。
三、什么是读写分离?
读写分离是主从复制的典型应用:写操作发给主库,读操作发给从库。因为多数业务是”读多写少”(浏览远多于发布/下单),把读分流到多个从库,能大幅提升整体承载。实现方式:应用层区分读写连接不同库、或用数据库中间件(如ProxySQL、MyCat)自动路由。
四、MySQL主从配置思路
以MySQL为例,主从配置的核心步骤(概念性):
- 主库:开启binlog(二进制日志)、设置唯一server-id、创建复制用账号;
- 从库:设置唯一server-id、配置连接主库的信息(CHANGE MASTER)、启动复制(START SLAVE);
- 验证:
SHOW SLAVE STATUS看 Slave_IO_Running 和 Slave_SQL_Running 都为Yes,表示复制正常。
PostgreSQL也有类似的流复制机制(参考PostgreSQL篇)。配置细节各版本有差异,按官方文档操作。
五、部署架构建议
主从架构对服务器和网络有要求:
- 主从最好分不同物理机:同一台机器上做主从,机器挂了主从一起完蛋,失去容灾意义。用两台独立服务器或裸金属;
- 主从之间走私有网络:复制流量走内网/私有网络(参考WireGuard篇),安全且不占公网带宽;
- 数据库机器要NVMe + 大内存:主从都是数据库,硬件要求一致(参考数据库服务器配置篇);
- 网络稳定:主从间网络抖动会导致复制延迟,同区域/同机房部署更稳。
六、注意事项
- 主从延迟:复制不是绝对实时,从库可能比主库慢一点点(通常毫秒到秒级)。对”写完立即要读到”的场景要注意(可让这类读走主库);
- 主从不等于备份:主库误删数据,从库会同步删除!主从是高可用,不能替代备份(参考备份篇仍要做);
- 故障切换:主库挂了切从库需要机制(手动或用工具如MHA、Orchestrator自动切换)。
七、什么规模需要上主从?
- 不需要:中小网站、单库压力不大——先做好单库优化(参考MySQL优化篇)和备份即可,别过早上复杂架构;
- 该上了:读压力大单库扛不住、业务不能承受数据库宕机、数据量大需要读扩展——这些信号出现时上主从(参考SaaS架构演进篇的阶段判断)。
结论
主从复制(数据同步到副本)+ 读写分离(写主读从)是数据库高可用和读扩展的基础:解决容灾、读扩展、备份不影响主库。上主从要点:主从分不同物理机、走私有网络、记住主从不能替代备份。按业务规模判断,别过早上、也别扛不住了才上。需要多台数据库机器时,物理独享的独立服务器是稳定的选择。
