1. 首页
  2. IT资讯

十七:主库的DUMP线程(笔记)

本文是我《深入理解MySQL主从原理》 系列的笔记部分,具体可以点击:ttps://j.youzan.com/yEY_Xi

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    

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7728585/viewspace-2649957/,如需转载,请注明出处,否则将追究法律责任。

主题测试文章,只做测试使用。发布者:深沉的少年,转转请注明出处:http://www.cxybcw.com/183956.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code