共计 3971 个字符，预计需要花费 10 分钟才能阅读完成。
本篇内容主要讲解“怎么理解主库的 DUMP 线程”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“怎么理解主库的 DUMP 线程”吧!
DUMP 线程启动函数调用流程
1、多次 select 交互，从库需要保存主库的信息
2、注册从库信息
3、读取从库发送的各种信息
com_binlog_dump_gtid
读取从库的信息包括
- server id
- 需要读取的 binlog 为名字
- 读取的位点
- 从库 GTID
- kill_zombie_dump_threads 杀掉本从库以前的 DUMP 线程 根据 UUID 和 SERVER_ID 联合判断
- mysql_binlog_send
- Binlog_sender sender 将读取的信息保存
- sender.run()
- Binlog_sender::init 初始化检测
- 主库 binlog 没开不允许连接 报错
Binary log is not open
- 如果 master server id 为 0 是不允许连接的报错
Misconfigured master - master server_id is 0
- 如果 GITD 协议下 GITD_MODE 主库必须为 ON，否则报错
The replication sender thread cannot start in
AUTO_POSITION mode: this server has GTID_MODE = %.192s
instead of ON.
- Binlog_sender::check_start_file() 进行从库 GTID 值是否可行的判断，并且打开文件也就是确认 binary log 的文件
- 取出从库关于主库 server_uuid 的 GTID 是小于等于 主库的 GTID 如果不是则报错
简单的说就是从库比主库多事物了。 比如主库 1:1-20 2:1-10 从库：1:1-15 2:1-30 判断 1 -15 是否小于等于 1 -20
Slave has more GTIDs than the master has, using the master s SERVER_UUID.
This may indicate that the end of the binary log was truncated or that the
last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1.
The master may or may not have rolled back transactions that were already replicated to the slave.
Suggest to replicate any transactions that master has rolled back from slave to master, and/or commit empty transactions
on master to account for transactions that have been committed on master but are not included in GTID_EXECUTED.
- 判断主库的主库的 GTID_PURGED 是否是从库 GTID 的子集 不是则报错
简单的说就是主库已经清理了从库拉取需要的 GTID。 比如主库 GTID_PURGED：1:1-10 2:1-5 从库 1:1-10 因为从库还需要 2:1-5 这些 GTID 主库已经没有了
报错
The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1,
but the master has purged binary logs containing GTIDs that the slave requires.
- 上面的情况还存在一种特殊情况比如主库手动删除了 binary logfile。这种情况 GTID_PURGED 可能没有更新需要
继续检查。 这一步涉及到实际的 binlog 扫描。先扫描最后一个 binlog 拿到 P_EVENT 检查是否 需要拉取的 GTID 是否在此之后。 是就结束，否则检查上一个 binlog 文件 同样拉取 P_EVENT 检查是否 需要拉取的 GTID 是否在此之后，如果延迟较高
并且设置了 relay log reocvery 参数的话这个过程可能有些长，比如几十秒。判断方式就是拉取 P_EVENT 来 判断是
否是需要的 GTID 的子集，正常情况这一步还是很快的。如果最后也没找到则同样报错，以前有朋友问我这一步是否
能够省略这里知道这一步是不能省略的原因就是前面说的 GTID_PURGED 可能不准，并且后面要需要打开这个 binlog 作为
扫描的起点 binlog
The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1,
but the master has purged binary logs containing GTIDs that the slave requires.
- 将文件存入 LOG_INFO m_linfo; 中 测试打开这个 binlog 文件
进入循环 会不断的读取下一个文件，如果不是历史 binary log
是当前文件 binary log 则会堵塞在 send_binlog 会不断的读取下， 这一层循环是循环的 binary log 文件
一个文件，如果不是历史 binary log 是当然 binary log 则会堵塞
- open_binlog_file 打开文件初始化读取缓存 IO_CACHE 初始化 CACHE 为读 CACHE 大小为 8K 文件指向相应的 binary log
- Binlog_sender::send_binlog
- 从初始化的位点开始读取
- get_binlog_end_pos 获取 binary log 的最后位置，如果是当前 binary log 则堵塞获取 并且发送心跳 EVENT
获取当前读取的位置
进入循环
获取当前 bianry log 的最后位点
- 如果不是当前 binary log
获取需要读取 binary log 的最后位置
如果 (log_pos == end_pos)
读取到文件尾部返回 0
否则返回最后位置
- 如果是当前 binary log
wait_new_events(log_pos) 等待新 event 的到来
进入状态 sending all event
- wait_with_heartbeat
主要逻辑就是通过 update_cond, LOCK_binlog_end_pos 来完成
如果没有新的 event 则 循环等待心跳 m_heartbeat_period 的描述
然后发一个心跳 event 给从库 携带当前 binlog 的位置。 如果有 break 退出循环了 return 1
pthread_cond_timedwait 实现 有兴趣可以看看这里的实现。 主要在于函数被信号唤醒返回 0 如果是超时为 etimeout。 - send_events 发送相应位置的 binlog 给从库
while 循环 为读取相应位置的 binlog event
- 获取 EVENT 的 TYPE
- 检查
- 如果是 auto_position=ON 不能有匿名 event 的存在 如果有则报错
Cannot replicate anonymous transaction when AUTO_POSITION = 1, at file %.512s, position %lld.
- 如果是 GTID_MODE=ON 不能有匿名 event 存在 否则报错
Cannot replicate anonymous transaction when @@GLOBAL.GTID_MODE = ON, at file %.512s, position %lld
- 如果是 GITD_MODE=OFF 不能有 GTID 的 event 存在
Cannot replicate GTID-transaction when @@GLOBAL.GTID_MODE = OFF, at file %.512s, position %lld
以上情况实际上如果正常操作是不会出现的，因为每次设置 GITD_MODE 总是会切换一个 binlog， 但是如果修改 GTID_MODE 不按照前面提到的流程可能会出现这些错误。 对于第一种错误很容易重现，因为 auto_postion 是 start slave 初始化传入的。 对于第二种和第三种错误因为 EVENT 的
生成线程和 DUMP 线程不是同一个线程是异步通知的方式，也就是说生成 GTID event 到发送这段时间
如果修改了 GTID_MODE 可能会出现这些问题。 - 上面只是取到 file name，POS 是从从库的 master info 传送过来， 这种情况下还会过滤掉从库已经执行的 GTID, 因此在 GTID 模式下主库
会进行再次过滤。更加安全。 - 发送 event到此，相信大家对“怎么理解主库的 DUMP 线程”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
正文完
