共計 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 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！