在从库的客户端执行show slave status\G；
有一个Seconds_Behind_Master，意思是从库执行的事务或者sql落后主库多长时间，还可以说是从库是主库多少秒之前的状态。
主从同步出现的延迟问题原因及解决方案
根本原因一、
重放中继日志超时
原因二、
主库的从库太多，导致复制延迟
从库数据以3-5个为宜，要复制的从节点数量过多，会导致复制延迟
原因三、
从库硬件比主库差，导致复制延迟
查看Master和Slave的系统配置，可能会因为机器配置不当，包括磁盘I/O、CPU、内存等各方面因素造成复制的延迟；关键一点是主库是多线程执行发送中继日志操作，从库是单线程重放中继日志。一般发生在高并发大数据量写入场景中
原因四、
慢SQL语句过多，或者从库承担很多业务分析（如统计数据很多都以从库下手，导致从库要干很多事，重放中继日志就慢）
假如一条SQL语句执行时间是20秒，那么从执行完毕到从库上能查到数据至少需要20秒，这样就延迟20秒了。
一般要把SQL语句的优化作为常规工作不断地进行监控和优化，如果单个SQL的写入时间长，可以修改后分多次写入。通过查看慢查询日志或show full processlist命令，找出执行时间长的查询语句或大的事务，比如事务还没有提交，那么也会导致主从不一致
原因五、
主从复制的设计问题
例如主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟。更高版本的Mysql可以支持多线程复制，门户网站则会开发自己的多线程同步功能。
原因六、
主从库之间的网络延迟
主从库的网卡、网线、交换机等网络设备都可能成为复制的瓶颈，导致复制延迟。另外，跨公网的主从复制很容易导致主从复制延迟
原因七、
主库读写压力大，导致复制延迟
架构的前端要加buffer及缓存层
门户网站的解决方案：
优酷的解决方案：数据库分片技术，而抛弃了由于数据量的越来越多导致复制延迟的问题。按照user_id进行分片，这样必须有一个全局的表来管理用户与shard的关系,根据user_id可以得到share_id，然后根据share_id去指定的分片查询指定的数据
淘宝的解决方案：修改源码，对应的机制是Transfer机制，此处通过对Binlog日志重做采用多线程实现，从而提高slave的QPPS
摘自：https://blog.51cto.com/szk5043/1762981
mysql 5.7使用按事务组并行的策略解决
了解一下配置项
binlog_group_commit_sync_delay
binlog_group_commit_sync_no_delay_count
binlog刷盘其实是两步动作，有一个配置binlog每次事务提交都会刷一下盘，避免binlog丢失数据丢失，让数据更安全。binlog刷盘是内存有一个binlog cache是缓存binlog，从binlog cache 到磁盘的binlog文件中间还有一步中转，是写到内存的binlog文件。
1：binlog_group_commit_sync_delay
全局动态变量，单位微妙，默认0，范围：0～1000000（1秒）。
表示binlog提交后等待延迟多少时间再同步到磁盘，默认0，不延迟。设置延迟可以让多个事务在用一时刻提交，提高binlog组提交的并发数和效率，提高slave的吞吐量。
2：binlog_group_commit_sync_no_delay_count
全局动态变量，单位个数，默认0，范围：0～1000000。
表示等待延迟提交的最大事务数，如果上面参数的时间没到，但事务数到了，则直接同步到磁盘。若binlog_group_commit_sync_delay没有开启，则该参数也不会开启。
MySQL5.7引入了基于逻辑时钟的并行复制的概念，让保守延迟困扰的我看到了一丝曙光。开心的将典型的库（6500/s TPS）升级到5.7之后，发现在默认的参数下提升并不明显。受Percona的关于并行复制这篇文章的启发，开始对参数binlog_group_commit_sync_delay调整对实际环境影响的验证。
slave_parallel_type=LOGICAL_CLOCK
备库slave_parallel_workers=10
调整binlog_group_commit_sync_delay
