遇到过下面几种造成主从延迟的情况: 1.主库DML语句并发大,从库qps高 2.从库服务器配置差或者一台服务器上几台从库(资源竞争激烈,特别是io) 3.主库和从库的参数配置不一样 4.大事务(DDL,我觉得DDL也相当于一个大事务) 5.从库上在进行备份操作 6.表上无主键的情况(主库利用索引更改数据,备库回放只能用全表扫描,这种情况可以调整slave_rows_search_algorithms参数适当优化下) 7.设置的是延迟备库 8.备库空间不足的情况下 这期的问题： 看这曲线,应该是从库正在应用一个大事务,或者一个大表上无主键的情况(有该表的更新) 应该是T3随着时间的增长在增长,而T1这个时间点是没变的,造成的现象就是 随着时间的增长,second_behind_master也是有规律的增长

老师，我先来讲个笑话 昨天去面试另一家公司，问mysql的问题，问罢之后。 面试官:我看你对mysql了解的还蛮深得，是不是也看了极客时间的。。。～ 我: 没有没有(连忙否认，有一种提前看了考试答案的罪恶感😂😂😂) 所以最后我有个问题，如果后面还有这样的问题，老师您觉得我应该怎么回答？

semi-sync在网络故障超时的情况下会退化成async，这个时候如果刚好主库掉电了，有些binlog还没有传给从库，从库无法判断数据跟主库是否一致，如果强行切换可能会导致丢数据，在金融业务场景下只能＂人工智能＂来做切换，服务中断时间长。AliSQL采用双通道复制更容易判断主备数据是否一致，如果一致可以自动切换，如果不一致才需要人工恢复数据。

总结下学习完高可用，老师有空帮忙看下 1、主备延迟，就是在同一个事务在备库执行完成的时间和主库执行完成的时间之间的差值，包括主库事务执行完成时间和将binlog发送给备库，备库事务的执行完成时间的差值。每个事务的seconds_behind_master延迟时间，每个事务的 binlog 里面都有一个时间字段，用于记录主库上的写入时间，备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时的差值。 2、主备延迟的来源①首先，有些部署条件下，备库所在机器的性能要比主库所在的机器性能差，原因多个备库部署在同一台机器上，大量的查询会导致io资源的竞争，解决办法是配置”双1“，redo log和binlog都只write fs page cache②备库的压力大，产生的原因大量的查询操作在备库操作，耗费了大量的cpu，导致同步延迟，解决办法，使用一主多从，多个从减少备的查询压力③大事务，因为如果一个大的事务的dml操作导致执行时间过长，将其事务binlog发送给备库，备库也需执行那么长时间，导致主备延迟，解决办法尽量减少大事务，比如delete操作，使用limit分批删除，可以防止大事务也可以减少锁的范围。 ④大表的ddl，会导致主库将其ddl binlog发送给备库，备库解析中转日志，同步，后续的dml binlog发送过来，需等待ddl的mdl写锁释放，导致主备延迟。 3、可靠性优先策略，①判断备库 B 现在的 seconds_behind_master如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步，②把主库 A 改成只读状态，即把 readonly 设置为 true，③判断备库 B 的 seconds_behind_master的值，直到这个值变成 0 为止； 把备库 B 改成可读写也就是把 readonly 设置为 false； 把业务请求切换到备库，个人理解如果发送过来的binlog在中转日志中有多个事务，业务不可用的时间，就是多个事务被运用的总时间。如果非正常情况下，主库掉电，会导致出现的问题，如果备库和主库的延迟时间短，在中转日志运用完成，业务才能正常使用，如果在中转日志还未运用完成，切换为备库会导致之前完成的事务，”数据丢失“，但是在一些业务场景下不可接受。 4、可用性策略，出现的问题：在双m，且binlog_format=mixed，会导致主备数据不一致，使用使用 row 格式的 binlog 时，数据不一致的问题更容易发现，因为binlog row会记录字段的所有值。 5、老师有个问题不太理解，就是主备延迟时，会导致备库在没有运用中转日志时，业务查询时导致”数据丢失“，那如何解决了？

请问老师，如果备库连接主库之后，主库的系统时间修改了，备库同步的时候是否会自动修正？

主备同步延迟，工作中常遇到几种情况： 1.主库做大量的dml操作，引起延迟 2.主库有个大事务在处理，引起延迟 3.对myisam存储引擎的表做dml操作，从库会有延迟。 4.利用pt工具对主库的大表做字段新增、修改和添加索引等操作，从库会有延迟。

循环复制根本原因是binlog中引入了非当前主机的server id，可以通过ignore server ids过滤，但是一般情况如果出现循环复制，数据的可靠性就值得怀疑了，不管是过滤还是重新找点都很难保证循环的部分完整执行过，最后都要验证数据的状态，属于特别严重故障😂

老师，图中产生的这个现象的原因应该是，执行一个大事务，导致second_behind_master一直在增加。 其实second_behind_master的计算机方法应该当前系统的时间戳减去sql_thread线程正在执行的binglog event上的时间戳，得到的差值就是seconds_behind_master. 但根据seconds_behind_master来判断主从同步有一个严重的问题，如果主库和从库网络如果不通，从库不会马上知道和主库连接不能，从库有一个 salve_net_timeout=多少秒，从库会通过这个参数定时的检测是否与主库保持通讯，所以这个参数应该设为小一点。slave_net_timeout=10(单位是秒). 或者用pt-hearbeat来检测主从延迟。 老师，请教一个题外问题，mysql的主从复制，到底是主库把binlog事件推送给从库，还是从库请求主库把binlog事件推送给从库。 除了start slave;这个动作表示从库请求把某一个binlog事件推送给它。因为一般情况下主库的binlog推送给从库是异步模式，不需要从库告诉主库我接收这个事件. 如果主从之间网络不通，主库会多次发送已经执行过的binlog事件吗？网络不好可能多次提交 实在抱歉

我有一个比较极端一点的HA问题，假设主库的binlog刚写成功还未来得及把binlog同步到从库，主库就掉电了，这时候从库的数据会不完整吗？ 第二个问题，原主库重启加入集群后，那条没有传出去的binlog会如何处理？

一般主从延时多少算是合理的？是秒级别吗？