怎么理解从库的IO线程

本篇内容介绍了“怎么理解从库的IO线程”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！一、流程解析
设置sync_master_info=1主库做一个大事务，观察slave_master_info表如下：主库执行：主库event 可以看到在中间下面是 recover_relay_log=0 的情况 POS和GTID AUTO_P开发云主机域名OSITION=1不同的处理。断点GTID
AUTO_POSITION binlog recover_relay_log=0的情况下：
DUMP线程会重新发送最后一个事务给从库，从库使用Crash前的Relay_Log_Pos进行读取。relay log可能出现不完整的事务。这种情况会触发回滚机制。单线程会在GTID event 中回滚，MTS会由协调线程调用coord_handle_partial_binlogged_transaction回滚主库：crash 后不完整的事物日志如下：启动后 IO_THREAD启动IO TRHEAD后 重新传输了，但是老的没有完全传输完成的日志还在relay log
新的日志已经有了 ，老的也还在。POSITION
在 recover_relay_log=0的情况下从库会从Read_Master_Log_Pos的位置接着拉取replay log，一旦Read_Master_Log_Pos和replay log出现问题那么将会导致从库异常。主库只需要从Relay_Log_Pos的位置应用即可。因此参数sync_relay_log=1sync_master_info=1
是必须的。写入途中：主库binlog：Crash启动后日志如下：从 end_log_pos 可以看到他们凑成了一个完整的事务日志。“怎么理解从库的IO线程”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注开发云网站，小编将为大家输出更多高质量的实用文章！

相关推荐: mysql索引分类、事务特性及查看视图简单介绍

本文主要给大家简单讲讲mysql索引分类、事务特性及查看视图，相关专业术语大家可以上网查查或者找一些相关书籍补充一下，这里就不涉猎了，我们就直奔主题吧，希望mysql索引分类、事务特性及查看视图这篇文章可以给大家带来一些实际帮助。key_name 对应的是索引…