怎么理解主庫的DUMP線程

本篇內(nèi)容主要講解“怎么理解主庫的DUMP線程”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么理解主庫的DUMP線程”吧!

在市南等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作定制網(wǎng)站制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計,成都營銷網(wǎng)站建設(shè),外貿(mào)營銷網(wǎng)站建設(shè),市南網(wǎng)站建設(shè)費用合理。

DUMP 線程啟動函數(shù)調(diào)用流程

1、多次select 交互，從庫需要保存主庫的信息
2、注冊從庫信息
3、讀取從庫發(fā)送的各種信息

com_binlog_dump_gtid
   讀取從庫的信息包括
   - server id
   - 需要讀取的binlog為名字
   - 讀取的位點
   - 從庫GTID
   - kill_zombie_dump_threads 殺掉本從庫以前的DUMP線程 根據(jù)UUID和SERVER_ID聯(lián)合判斷
   - 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協(xié)議下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的文件  
           - 取出從庫關(guān)于主庫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的子集 不是則報錯
             簡單的說就是主庫已經(jīng)清理了從庫拉取需要的GTID。
             比如主庫GTID_PURGED：1:1-10 2:1-5 從庫 1:1-10  因為從庫還需要2:1-5 這些GTID 主庫已經(jīng)沒有了
             報錯
             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可能沒有更新需要
             繼續(xù)檢查。
             這一步涉及到實際的binlog掃描。先掃描最后一個binlog 拿到P_EVENT檢查是否 需要拉取的GTID是否在此之后。
             是就結(jié)束，否則檢查上一個binlog文件 同樣拉取P_EVENT檢查是否 需要拉取的GTID是否在此之后，如果延遲較高
             并且設(shè)置了relay log reocvery參數(shù)的話這個過程可能有些長，比如幾十秒。判斷方式就是拉取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 文件
       進入循環(huán)  會不斷的讀取下一個文件，如果不是歷史binary log 
       是當前文件binary log則會堵塞在send_binlog 會不斷的讀取下，
       這一層循環(huán)是循環(huán)的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則堵塞獲取 并且發(fā)送心跳EVENT
           獲取當前讀取的位置
           進入循環(huán) 
           獲取當前bianry log的最后位點
           - 如果不是當前binary log
             獲取需要讀取binary log的最后位置
             如果(log_pos == end_pos)
             讀取到文件尾部返回0
             否則返回最后位置
           - 如果是當前binary log
             wait_new_events(log_pos) 等待新 event的到來 
              進入狀態(tài) sending all event
               - wait_with_heartbeat
                 主要邏輯就是通過 &update_cond, &LOCK_binlog_end_pos來完成
                 如果沒有新的event則 循環(huán)等待心跳m_heartbeat_period的描述
                 然后發(fā)一個心跳event 給從庫 攜帶當前binlog的位置。
                 如果有break 退出循環(huán)了return 1
                 pthread_cond_timedwait 實現(xiàn) 有興趣可以看看這里的實現(xiàn)。
                 主要在于函數(shù)被信號喚醒返回0 如果是超時為etimeout。
         - send_events 發(fā)送相應位置的 binlog 給從庫
           while循環(huán) 為讀取相應位置的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
             以上情況實際上如果正常操作是不會出現(xiàn)的，因為每次設(shè)置GITD_MODE總是會切換一個binlog，
             但是如果修改GTID_MODE不按照前面提到的流程可能會出現(xiàn)這些錯誤。
             對于第一種錯誤很容易重現(xiàn)，因為auto_postion是start slave初始化傳入的。
             對于第二種和第三種錯誤因為EVENT的
             生成線程和DUMP線程不是同一個線程是異步通知的方式，也就是說生成GTID event到發(fā)送這段時間
             如果修改了GTID_MODE可能會出現(xiàn)這些問題。
           - 上面只是取到file name，POS 是從從庫的master info 傳送過來，
             這種情況下還會過濾掉從庫已經(jīng)執(zhí)行的GTID,因此在GTID模式下主庫
             會進行再次過濾。更加安全。
          -  發(fā)送event

到此，相信大家對“怎么理解主庫的DUMP線程”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！

網(wǎng)頁名稱：怎么理解主庫的DUMP線程
標題網(wǎng)址：http://muchs.cn/article22/jehicc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、自適應網(wǎng)站、全網(wǎng)營銷推廣、Google、網(wǎng)站建設(shè)、做網(wǎng)站

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容