背景介紹：試用報告資料在db底層打通評價資料，報告資料就分散到評價的32個資料庫，2048張表裡。因為基本的業務需求是打通資料並且將報告接入搜尋。為了考慮業務靈活性，選擇終搜平台來完成報告的全量和增量。全量模組通過tsearch
基於評價以及ic的雲梯表，join做的全量dump。因為增量通過sql的增量方式，會給db造成很大的壓力，尤其是在gmt_modified 沒有索引的情況，並且數量級百億的資料來源中增量百萬級的資料。
本文主要介紹用mysql的binlog解析得到的穩定增量資料來源來解決非sql增量的方案。
一、整體設計
先看一下全量和增量整體的專案架構圖
上圖左邊部分是全量部分，通過hadoop
寫全量job去dump資料。右半部分是增量模組，通過drcdatasource實現獲取mysql解析binlog 得到的modified資料，主要是通過drc（data replication center）平台提供訊息資料介面。然後應用通過接收資料更新訊息，獲得增量資料來源，並將處理分解後的資料更新到終搜的增量資料來源中，通過實現終搜定製的dataprovider來讓終搜增量定時任務掃瞄每2分鐘的增量。
二、增量方案
增量的系統互動時序圖如下：
增量的資料目的地是增量索引檔案。那麼索引檔案的資料來自於搜尋平台提供的乙個sourcedataprovider。在這裡，是應用自己實現的dataprovider,命名為reportdataprovider。資料提供格式是list
splitlist。也就是說，我們需要填充增量資料到這個list中。再往下一步這個list資料就**於drc平台。然後drc平台通過解析mysql的binlog來獲得資料庫的實時變更資料。應用平台需要做的就是接收變更資料的訊息，將變更資料的行資料put到dump需要的分塊資料（也就是上述splitlist）中。
加上構建搜尋增量索引部分的流程，整體增量時序圖如下：
三、binlog解析及實時增量技術
在了解了增量設計方案之後，我們可以繼續深入到資料來源的獲取和解析。下面簡單介紹下mysql日誌模組的一些基本概念，以及通過row模式解析binlog，獲取到元資料metadata以及資料行資訊的方式。
1、mysql
log介紹
mysql
的日誌型別有查詢日誌、錯誤日誌、慢查詢日誌以及二進位制日誌等。這裡簡單說一下二進位制日誌(binlog)，二進位制日誌記錄了對資料庫的更改操作，如create,insert,drop,update等。通過二進位制日誌可以對資料庫進行資料恢復以及資料複製。
2、binlog 幾種模式介紹
開啟二進位制日誌是需要手動指定引數，但是開啟日誌也會對效能造成一定影響，這個可以參看mysql官方手冊不同版本的影響。但是考慮其可以用在複製和恢復資料的作用上，可以通過手動配置一些引數來最大化利用好二進位制日誌。其中binlog_format引數在mysql5.1之後可以用statement,row，mixed三種模式。
statement是mysql一直以來支援的格式，記錄的是日誌的邏輯語句。row格式下就可以記錄行的更改情況，對於資料複製和恢復的可靠性更好，但同時也會增加二進位制檔案的大小。mixed格式是綜合了前兩者，具體要看儲存引擎的支援情況。innodb和myisam是statement,row兩者都支援的。
3、binlog
解析（細化，圖形加例子描述）
binlog檔案就像乙個流檔案，它每一條記錄沒有明顯的開始及結束標誌，它是通過長度來判斷一條記錄的結束位置，所以在分析binlog檔案的時候總是必須從頭開始，然後依次一條一條的讀取。binlog的頭資訊是固定的，要分析資料其實要讀完整個檔案。mysql官方有提供了mysqlbinlog 工具來檢視日誌。當然我們也可以通過程式去解析二進位制檔案成我們想要看到的輸出格式。
把binlog分成幾個模組來看的話，開始的部分都是由fe
62 69 6e4個位元組組成的魔數，接下來的部分就是common-header，再後面就是body部分。下面簡單列舉下**模組，看一下解析過程
1.獲取binlog檔案，解析固定的魔陣列：
public inputstream parseinit(string path)throws exception;
finalbyte inputmagic
= newbyte[binlogmagic.length];
inputstream.read(inputmagic, 0,
binlogmagic.length);
if(!arrays.equals(inputmagic, binlogmagic))catch(exception
e){inputstream.close();
throw e;
2.解析common-header部分
也就是將header的固定位元組數的部分讀出來。下面**模組表示了每個解析模組代表的含義以及位元組數。
long timestamp= inputstream.readlong(4);//操作前的時間戳
int type= inputstream.readint(1);// 事件型別，標記了操作型別，事務提交或者查詢等。
long serverid= inputstream.readlong(4);// 事件建立的server id。
int eventlength= inputstream.readint(4);// 該條記錄的size
long nextposision= inputstream.readlong(4);//下條記錄起始位點
int flag= inputstream.readint(2);
3. 解析event
binlog記錄的event有20多種，每個ddl會出發多個event。比如update，insert，delete 等操作都會觸發產生table_map_event 來獲取資料庫的元資料，對於庫、表的資訊。所以下面的解析就要針對event。因為具體的event所對應的資料格式，位元組分配都是不同的。這裡不列舉具體某個解析**，在設計的過程中，可以參考visitor模式 來設計。如下圖：
四、總結
綜上，在我們考慮介入增量搜尋的時候，可以考慮對於db壓力更小，效能更優的方式來dump資料來源。尤其，未來業務快速發展，報告的資料也不再侷限在一張邏輯表裡面的時候，用好二進位制日誌，可以幫助我們更好地去做好資料的過濾、組合，處理。本文只是對於增量搜尋乙個既有實施方案的設計以及思考。對於不同的應用場景，需要未來進一步地**，以及更加適合應用和優效能的方案。
MySQL利用binlog增量恢復資料庫
資料庫中表被誤刪除 恢復方法 首先分析表是否重要 1 重要的情況處理 1 停服務，掛維護頁面，保證資料一致性 2 找乙個新的資料庫做恢復測試，同時對故障庫進行備份 3 恢復前日備份，恢復完畢後 拷貝 binlog過來 4 查詢binlog位置，獲取故障前一刻binlog位置 追binlog 5 啟動...
mysql使用binlog實現增量備份指令碼
使用binlong日誌實現mysql的增量備份 root mysqltest cat a.sh bin bash bakdir mnt 備份檔案存放的路徑 bindir data mysql log binlog日誌的路徑 logfile data mysql log bak.log 日誌存放路徑 ...
binlog恢復資料
記一次誤刪恢復資料 通過binlog日誌檔案生成時間和誤操作刪除資料的時間對比,分析出生成到哪個檔案中 兩種恢復方式 1 通過時間段 usr local mysql bin mysqlbinlog start datetime 2019 10 11 19 00 00 stop datetime 20...