怎么理解主库的DUMP线程

本篇内容主要讲解“怎么理解主库的DUMP线程”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么理解主库的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线程”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！