MySQL 的主从复制，说实话，是我用下来觉得还蛮稳定的一种高可用方案。主库写、从库读，逻辑简单，配置也不算太复杂，尤其适合中小型项目做读写分离。
主服务器的 binlog就像是流水账，记录了所有的写操作；从服务器则负责拉这些账单过来照着抄。两边配合默契，一边写、一边读，效率还挺高的。
整个复制流程主要靠两个线程：I/O 线程拉日志、SQL 线程来执行。要是你用得熟，优化起来也方便，比如 binlog 改成ROW格式，延迟能降不少。
配置主从也没多难，核心就几个步骤：主库开启binlog、设置复制账号、记下日志位置，在从库上填好主库信息，启动复制线程。几步搞定，响应也快。
不过复制过程中也不是没有坑。比如数据不一致，常见的原因是从库太慢或者网络卡顿。这种时候可以用半同步复制，稳一点；还有个叫GTID的东西，也挺好用，能自动追踪事务，方便故障切换。
说到高可用，主从复制只是起步。想要更强大？可以看看像Percona XtraDB Cluster这种集群方案，或者搞个多级复制，把数据多备份几份，保险一点。
哦对了，实际操作过程中如果你遇到线程状态卡在Waiting for master to send event，多数是网络问题或者主库写入慢，先别慌，检查下主库状态和show slave status输出，多半能找出原因。
想进一步了解或者动手试试，可以看看这些：
- 配置主从复制，一步步搭建流程
- 多线程主从复制工具，提升并发性能
- Kubernetes 下部署 MySQL 主从，更现代的部署方式
- Windows 系统下配置主从，本地环境也能玩
- binlog 日志刷新实战，进阶优化参考
如果你在做读写分离、热备方案，或者只是想了解下 MySQL 的复制机制，这套主从配置的套路值得一试。