這是我的學(xué)習(xí)筆記咕痛，粗略記錄備忘
uint64：無符號8字節(jié)整數(shù)
uint32：無符號4字節(jié)整數(shù)
我們知道一個事務(wù)的binlog一定在一個binlog文件里面休涤，其實一個group commit的事務(wù)都應(yīng)該在一個binlog里面丰滑，那么很可能這個binlog的大小會大于4G果善∮艏荆可以參考這篇文章：
http://www.reibang.com/p/10082cb72c42
截取部分解析如下：
事實上在第10步中我們只是設(shè)置了切換標(biāo)記而已戴质，實際的切換會等到本事務(wù)所在的commit隊列都提交完成后才會進行binlog的切換，具體就是參考第28步式撼。
在這個期間會有2個原因?qū)е麓笫聞?wù)并不是binlog的最后一個事務(wù)：
對于flush隊列而言童社，大事務(wù)可能包含在隊列中的某個位置，隊列后面可能包含小事務(wù)著隆。
對于sync隊列而言扰楼，大事務(wù)的提交會在sync階段耗費很多時間呀癣，如果我們假設(shè)為30秒，那么在這30秒內(nèi)其他新的事務(wù)是可以進入新的flush隊列的弦赖，也能夠進行寫binlog（不是fsync）的操作项栏。
因此線上有壓力的庫，binlog的最后一個事務(wù)通常不是大事務(wù)蹬竖。
那么考慮這個問題沼沈，主要是因為，而且某些其他工具比如OGG等會遇到問題币厕。
- binlog內(nèi)部的event的end log pos為4字節(jié)列另，如果binlog大于4G如何處理？
- 同時主從協(xié)議中可能位點的存儲為4字節(jié)旦装，如果binlog大于4G如何處理页衙？
很顯然uint32 最大值就是4G，那么主從該如何處理阴绢，而end log pos如何存儲呢店乐？
一、測試圖
由于我本機已經(jīng)沒有那么大的空間進行測試了呻袭，因此沿用老的一張朋友的測試圖如下：
我們這里可以看到隨著binlog的增大眨八，binlog的大小已經(jīng)超過了4G，但是end log pos直接重新循環(huán)為3601大小棒妨。
二踪古、end log pos為什么重新循環(huán)了
大概這個寫入路徑，當(dāng)我們執(zhí)行提交到 flush階段的時候會寫入我們的binlog券腔，我們稍微看看end log pos的計算方式：
uint32 end_log_pos
// Increase end_log_pos
end_log_pos+= *event_len_p;
這里應(yīng)該是溢出了伏穆，也就是將uint64截取了剩下的4個字節(jié)直接賦予給了end_log_pos（uint32），我們直接驗證一下如果纷纫，我將uint64的4294970897賦予給uint32的變量如下：
[root@mgr4 ~]# ./a.out
3601
我們可以發(fā)現(xiàn)和第一節(jié)超過4G后的end log pos一致了枕扫。這應(yīng)該是end log pos重新循環(huán)的原因。但是這個值是在show slave status的時候讀取和執(zhí)行主庫binlog position的位點辱魁，當(dāng)前不知道show slave status是否會出現(xiàn)問題烟瞧，這個也比較容易測試，做一個超大的事務(wù)大于4G就可以測試出來染簇。當(dāng)前翻閱的邏輯占時沒有找到如何處理参滴。
三、主從協(xié)議postition為4字節(jié)的問題
這個問題考慮一個情況锻弓，如果我們大于4G的部分包含多個事務(wù)砾赔，也就是一個group commit，如下：
事務(wù)1、事務(wù)2暴心、事務(wù)3位組提交妓盲，包含在一個binlog里面
事務(wù)1 -->大于4G
事務(wù)2 -->從庫crash
事務(wù)3
這個時候如何指向事務(wù)2和事務(wù)3的位置繼續(xù)。這個時候看起來基于傳統(tǒng)position的方式是硬傷专普。代碼注釋如下：
com_binlog_dump（傳統(tǒng)基于位點的主從）
/*
4 bytes is too little, but changing the protocol would break
compatibility. This has been fixed in the new protocol. @see
com_binlog_dump_gtid(基于GTID AUTOPOSITION的主從).
*/
也就是說我們應(yīng)該使用GTID AUTOPOSITION來避免這個問題悯衬，我們可以看到確實也有這種大于4G的考慮在里面。如果是GTID字段尋址檀夹，然后將得到的位點保存在一個uint64的變量中筋粗，結(jié)合event中的event len即可繼續(xù)讀取。尋址的起始位點如下（dump線程讀取event見下一節(jié)）：
unsigned long long
my_off_t start_pos
看來我們真的應(yīng)該多使用GTID AUTOPOSITION方式了击胜。
四亏狰、DUMP線程讀取
前面是初始化尋址存儲在unint64變量中，一旦我們尋址成功了偶摔，那么接下來就是循環(huán)讀取event了。這里使用的是start_pos+event len的方式來不斷的向下讀取促脉，意思就是說如果start_pos正確則可以繼續(xù)讀取了辰斋。大概如下（Log_event::read_log_event）：
(my_b_read(file, (uchar*) buf, LOG_EVENT_MINIMAL_HEADER_LEN)) //讀取event header
data_len= uint4korr(buf + EVENT_LEN_OFFSET);
my_b_read(file,reinterpret_cast<uchar*>(event_data_buffer),data_len);
這里我們看到讀取了event的header 然后獲取了data len，然后file里面包含了start_posgitd也就是通過找到的起始位點瘸味，那么就可以依次讀取到event了宫仗。這里實際上也不基于end log pos，因此DUMP可以正常讀取event即便大于4G旁仿。
五藕夫、未盡事宜
- 對于大于4G的binlog主從正常的情況下，show slave status如何顯示枯冈？
- 可以限制事務(wù)的最大binlog量通過max_binlog_cache_size毅贮，建議值4G，看來也是有這些原因在里面尘奏。
- 其他限制滩褥？
