图中master thread是每1s从redo buffer刷新redo到磁盘。
dump thread将binlog推送到远程的slave，每一个slave会对应一个dump thread
接收IO线程和回放SQL线程的单位是event(write_row等等)，5.6之前SQL线程只有一个线程，而主库上执行是多线程的，延时较大。
从5.6开始支持多线程，之前的SQL Thread作为协调的线程，真正回放的线程是Work Thread，但是5.6有一个问题，Work Thread是和库对应的，一个库对应一个Work Thread，5.7开始备库和主库一致。
还有两个重要的文件，master-info.log和relay-info.log，master-info.log表示IO线程接收到的pos的位置(event的位置)，relay-info.log表示回放到的pos位置。
至于是dump thread推还是slave过来拉日志，其实是推拉结合的？
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29990276/viewspace-2055728/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
binlog日志的格式
下一篇：
5.7 mysql的可传输表空间
请登录后发表评论
登录
全部评论
最新文章
- chrony /ˈkrɑːni/ vs ntpd 的核心区别
- LightDB新特性-Oracle模式支持回收站功能
- centos stream 8
- benchmarksql 压测MySQL报Every derived table must have its own alias解决
- LightDB-A gpfdist 命令初体验
- 数据库的sort group by和hash group by
- PostgreSQL citus常见报错问题分析（二）DETAIL: Distributed relations cannot have
- 事务可见性的判断和事务隔离级别，PostgreSQL和MySQL实现上有啥区别
- LightDB Canopy 常见报错问题分析（一）
- LightDB/postgresql内置特性之访问oracle之oracle_fdw介绍
