现在公司业务一多，数据库单点跑就容易出问题。要是主库挂了，整个系统就瘫了，数据丢了更是麻烦。为了解决这个事，MySQL 8的主从复制就能派上用场，它能让数据在主库和从库之间同步，保证业务不停。

主从复制的核心其实不复杂，主要靠三个东西干活。主库这边有二进制日志，就是那个Binlog，还有专门的Dump线程，负责把数据变更记录下来。从库那边有两个线程，一个是I/O线程，专门从主库拉日志，另一个是SQL线程，负责把拉回来的日志在从库上重放一遍。

Binlog的格式有三种，现在默认是ROW模式，记录每行数据的变化，这样最安全，不会出现主从不一致。不过ROW模式的日志会大一些，但好在可以设置只记录变更的列，能省点空间。

复制模式的选择也挺重要。异步复制性能最好，主库写完就完事，不管从库有没有收到，但主库崩了可能丢数据。半同步复制是折中方案，主库要等至少一个从库确认收到才提交，这是生产环境最常用的。组复制要求更高，数据零丢失，但性能损耗也大。

搭建主从复制有两种方式，一种是基于Binlog文件位置的传统复制，另一种是GTID复制。GTID复制更先进，不用手动找文件位置和偏移量，主从切换时自动匹配，特别适合运维。现在新项目都建议直接用GTID，省心很多。

搭建的时候，主库要开Binlog，配好server-id，从库也要配好server-id和中继日志。从库要设成只读，防止意外写入。复制用户要单独创建，权限只给复制权限就行。

主从复制最让人头疼的就是延迟问题。延迟原因有很多，最常见的是大事务，比如一下子删几百万行数据。解决办法是把大事务拆成小批量，或者用工具分批次处理。

从库的SQL线程是单线程的，遇到主库写压力大就容易跟不上了。这时候可以开启多线程复制，让多个线程并行执行，能明显提升速度。网络延迟和从库硬件差也会导致延迟，要保证主从之间网络稳定，从库硬件配置别太差。

监控主从状态很重要，主要看那几个关键指标。Seconds_Behind_Master是最直观的延迟指标，但有时候不准，得结合GTID集合来看。I/O线程和SQL线程是否正常也是基本检查项。

平时可以写个脚本定时检查复制状态，延迟超过一定时间就报警。推荐用Prometheus和Grafana搭监控，能全面看到MySQL实例的各种状态。

总的来说，主从复制就是日志传输和重放的过程。新项目推荐用GTID，生产环境开半同步，从库只读，定期巡检。主从服务器硬件配置最好一致，别出现木桶效应。主库也要定期备份，不能完全依赖从库。