前言
主从同步关注四个问题：
- 主从复制原理；
- 主从复制的数据丢失问题，以及半同步复制的原理；
- 主从延迟问题产生的原因；
- 并行复制的原理，多库并发重放relay log日志，缓解主从延迟问题。
二，主从同步原理
主库对所有DDL和 DML产生 Binlog，I/O线程 读取Binlog 内容写入到 Relay log 文件中，从数据库生成一个 SQL线程 读取 Relay log 文件中的日志,并解析成sql语句逐一执行。
三，主从复制的数据丢失问题
如果主库突然宕机，然后恰好数据还没同步到从库，将造成数据丢失问题。
半同步：
开启 semi-sync 同步。
指主库写入 binlog 日志后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的ack之后才会认为写操作完成。
全同步：
主库插入数据后，等待，写入从库数据库后，结束等待。
四，主从同步延迟原理
MySQL 的主从复制都是单线程的操作，主库对所有 DDL 和 DML 产生的日志写进 binlog，由于 binlog 是顺序写，所以效率很高。 Slave的 SQL Thread 线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的，不是顺序的，成本高很多。 另一方面，由于 SQL Thread 也是单线程的，当主库的并发较高时，产生的 DML 数量超过slave的 SQL Thread 所能处理的速度，或者当 slave 中有大型 query 语句产生了锁等待那么延时就产生了。
主要是看主库的**写并发**！
通过测试，主库写并发达到 1000/s ，从库延迟会有 几毫秒；主库写并发达到 2000/s ，从库延迟会有 几十毫秒；主库写并发达到 4000/s 或以上，从库延迟会有 几秒；
五，主从同步延迟解决方案
① 打开 MySQL 并行复制。
MySQL 5.6.x 版本引入并行复制，但此版本是库并行，每个库一个SQL线程去同步数据。如果大部分操作都集中在一个库，那么这个并行复制起到的左右并不大；
Mysql 5.7 对 “并行复制” 进行了改善，可以按照逻辑时钟的方式来分配线程，大大提高了复制性能。
② 优化代码逻辑，考虑刚写入的数据可能不能马上查询到；
③ 分库，降低写并发；
④ 若刚写入的数据须马上查询到，可采用直连主库查询。（不推荐，丧失读写分离意义）
⑤ 升级Slave硬件配置；
六，mysql集群方案
一主一从：
主要用于数据热备，提高可用性，但不可以代替数据的备份（master执行drop，从库数据也会丢失）。
如何做数据恢复？备份+binlog。
一主多从：（多用于读写分离）
从库不是越多越好，多了数据同步压力大，一般2-4个从库。
若：有4个从库，可以留一个从库做特殊业务处理，慢SQL查询、或开发人员在此从库上查看线上问题。不影响其它节点，有效隔离。
用简单的架构方案解决问题，能用一主一从解决，不用一主多从，等。
文章参考：
MySQL主从复制的简单搭建
评论区