（1）主从延迟：
    主从复制可能会有较大的延迟。这个延迟就是主库可能都写入100条数据了，结果从库才复制过去了50条数据，那么从库就比主库落后了50条数据，这就是主从延迟问题。
    为什么会产生主从延迟这个问题？其实主库是多线程并发写入的，所以主库写入数据的速度是很快的，但是从库是单个线程缓慢拉取数据的，所以才会导致从库复制数据的速度是比较慢的。
    那么主从之间到底延迟了多少时间呢？这个可以用一个工具来监控，比较推荐的是percona-toolkit工具集里的pt-heartbeat工具，这个工具会在主库里创建一个hearbeat表，然后会有一个线程定时更新这个表的时间戳字段，从库上就有一个monitor线程会负责检查从库同步过来的heartbeat表里的是时间戳，把时间戳和当前时间戳比较一下，就知道主从之间同步落后了多长时间了，总之，主从之间延迟了多长时间，实际上是可以看到的。

    （2）主从同步延迟会导致一些什么样的不良情况？
    如果做了读写分离架构，写都往主库写，读都往从库读，那么会不会刚写入一条数据到主库，接着代码里立即就从从库里读取，可能此时从库复制有延迟，会读不到刚写入进入的数据，这是我们经常遇到的问题，另外就是从库同步数据太慢，导致从库读取的数据都是落后和过期的，也可能导致系统产生一定业务上的bug，所以针对这个问题，首先应该做的，是尽可能缩小主从同步的延迟问题。

    （3）如何缩小主从同步的延迟问题？
    其实就是让从库也用多线程并发复制数据就可以了，这样从库复制数据的速度快了，延迟就会降低，MySQL5.7就已经支持并行复制了，可以在从库里设置 slave_parallel_worker>0，然后把slave_parallel_type设置为 LOGICAL_CLOCK 就可以了。
    另外如果还是要求刚写入的数据立即强制必须都一定可以读到，此时可以使用一个办法，就是类似Mycat或者Sharding-Sphere之类的中间件里设置强制读写都从主库走，这样写入主库的数据，强制从主库里读取，一定立即可以读到的。

    （4）总结：
    总体而言就是这样，在落实读写分离架构的时候，要注意一下复制方式，是异步还是半同步，如果说对数据丢失并不是强要求不能丢失的话，可以用异步模式来复制，再配合一下从库的并行复制机制，如果对MySQL做高可用保证数据绝对不丢失的话，建议用半同步机制好一些，同理最好配合从库的并行复制机制。

    问题点1：这里的主从延迟应该是异步复制的时候产生的，半同步不会产生主从延迟，半同步复制会等待从库收到relay log后才会返回结果给客户端
    问题点2：如果并行复制主库收到两条sql，一个insert，一个update，update基于insert数据操作，那update找不到更新的这条SQL语句如何处理？
    binlog模式可以改为完整数据，别使用逻辑的update语句。
    binlog日志模式：
    https://www.linuxidc.com/Linux/2018-08/153612.htm
    https://www.huaweicloud.com/articles/d72a16ccd827c95d99d5298e52ec41bc.html

    查看MySQL的binlog的日志模式：show global variables like ‘%binlog_format%’;

    percona-toolkit使用

    1. https://www.cnblogs.com/zishengy/p/6852280.html
    2. https://www.codenong.com/cs106108843/