1、SANGFORAC 3.2&SG3.2 新產(chǎn)品培訓.培訓內容培訓目的AC3.2&SG3.2新產(chǎn)品培訓能說出三種以上AC3.2&SG3.2版本解決的問題。掌握什么情況下需要選用AC3.2&SG3.2版本。掌握3.2版本數(shù)據(jù)審計及數(shù)據(jù)同步原理.目錄一、3.2詳細處理了哪些問題二、日志審計三、日志同步四、中間表五、日志精簡六、晉級及本卷須知七、FAQ.1.數(shù)據(jù)庫插入速度慢。 在帶寬較大大于240Mb的情況下，產(chǎn)生日志的速度大于數(shù)據(jù)庫插入的速度，產(chǎn)生漏審計。2.數(shù)據(jù)恢復機制差。 在數(shù)據(jù)庫異常解體后，會喪失全部歷史日志。3.同步與統(tǒng)計數(shù)據(jù)慢。 3.2之前版本日志量大(A表日志超越2000萬條，附件數(shù)超越

2、25萬)的時候，日志同步速度慢或異常停頓，3.2版本支持A表6000萬條日志同步。4.審計冗余日志過多。 冗余日志太多，導致審計性能下降。5.數(shù)據(jù)庫收縮。 處理數(shù)據(jù)庫表刪除后，數(shù)據(jù)庫占用硬件空間大小沒有釋放的問題。一、3.2詳細處理了哪些問題.培訓內容培訓目的日志審計能說出3.2版本在寫日志方面較之前版本有哪些改進。能說出高性能模式和普通模式的區(qū)別。能說出MYSQL改用存儲引擎解決了什么問題。二、日志審計.3.2之前版本日志審計3.2以前的版本由aclog直接寫內置 mysql數(shù)據(jù)庫，經(jīng)過insert命令逐條插入數(shù)據(jù)庫的，如圖，日志寫入速度及同步速度比較慢。1、對比之前版本.3.2版本日志審計

3、AC3.2版本Aclog改動日志逐條地插入到數(shù)據(jù)庫中的機制，而是生成日志文件sync_file和load_file，再由日志導入模塊Loader擔任將日志批量導入到數(shù)據(jù)庫中。處理以往版本由aclog直接將日志逐條插入數(shù)據(jù)庫的效率低問題。1、對比之前版本續(xù). aclog將日志寫到兩個文件中：sync_file和load_file。sync_file是5分鐘寫一個文件，load_file間隔時間比較短5s。 sync_file主要功能是：向外置數(shù)據(jù)中心同步數(shù)據(jù)或者恢復內置mysql。它里面保管的日志和內置mysql一樣。 load_file主要功能是：日志中轉，實現(xiàn)批量向內置的mysql插入數(shù)據(jù)，

4、而且它里面的日志在被loader導入完成后自動刪除。1、對比之前版本續(xù). 在客戶日志量很大的情況下，為了提高AC數(shù)據(jù)同步性能，AC可以啟用高性能方式，在高性方式下，aclog只會寫sync_file下的文件，不會寫load_file的文件，所以內置數(shù)據(jù)中心無日志記錄，只進展外置數(shù)據(jù)日志同步。啟用高性能方式如以下圖。2、高性能方式.2、高性能方式續(xù). AC3.2版本采用日志批量導入數(shù)據(jù)庫及日志損壞自動修復機制，分別由load和recover程序實現(xiàn)。處理了日志寫入慢及日志庫損壞無法修復的問題，loader和recover同樣適用于外置數(shù)據(jù)中心。如上圖3、日志導入及恢復機制.3.1.Loader經(jīng)

5、過檢測能否存在load_file文件5S，假設存在那么將load_file里面的日志導入數(shù)據(jù)庫。3.2.Loader向MYSQL導入數(shù)據(jù)，正常結導入勝利后，把load_file文件進展刪除。3.3.假設Loader導入表失敗并且自行修復表，那么調用Recover進展修復。3.4.Revocer從sync_file中，把導入失敗的表，進展重新復原導入。導入勝利那么前往給Loader。3.5.假設導入不勝利，償試三次都失敗。那么回復相應的錯誤給Loader，并且交還控制權給Loader。3、日志導入及恢復機制續(xù). AC3.2版本數(shù)據(jù)中心采用myisam數(shù)據(jù)庫存儲引擎，AC3.2之前版本采用inno

6、db數(shù)據(jù)庫存儲引擎，innodb存儲引擎存在以下兩個問題：無法釋放數(shù)據(jù)庫空間 某天或某幾天的表損壞，能夠導致整個數(shù)據(jù)庫損壞，從而導致整個日志喪失。Myisam存儲引擎有效地處理了上述兩個問題4、數(shù)據(jù)庫存儲引擎myisam.Myisam存儲引擎特點是每天的每種表都是單獨存儲的，益處是某個表損壞了，還可以再重新load一次修復。這種方式的數(shù)據(jù)庫會有很多文件，比如20211130的A表就會產(chǎn)生三個文件：A20211130.frm構造表、A20211130.MYI索引表、A20211130.MYD日志表。4、數(shù)據(jù)庫存儲引擎myisam(續(xù)).5.1、3.2日志審計不再由aclog直接寫數(shù)據(jù)庫。改成ac

7、log直接把日志寫到sync_file和load_file兩個文件中。每隔一段時間，一次性導入一批日志記錄，從而極大提高了效率。5.2、sync_file文件存在硬盤上，用于同步到外置數(shù)據(jù)中心和內置數(shù)據(jù)庫恢復運用，每五分鐘生成一個文件。Load_file用于導入到內置數(shù)據(jù)庫中，導入勝利后便刪除，每5s左右導入一次。5.3、Sync_file與內置數(shù)據(jù)中心存放著一樣的日志，所以產(chǎn)生一個問題，磁盤運用率降低一半。5.4、支持某一天的日志表壞了，可以直接從日志文件(sync_file)中恢復。只支持恢復當天的，暫時不支持內置數(shù)據(jù)庫完全掛掉后，全盤恢復。但是可以運用外置數(shù)據(jù)中心，把日志文件中的日志導出

8、。5.5、啟用高性能方式的時候，aclog只寫sync_file文件，內置數(shù)據(jù)中心無日志。5.6、MYSQL改myisam為存儲引擎，處理數(shù)據(jù)庫收縮問題。5、日志審計總結.培訓內容培訓目的日志同步。了解數(shù)據(jù)同步整體過程了解外置數(shù)據(jù)日志導入load及日志恢復recover功能能說出什么情況下建議用壓縮算法三、日志同步. 3.2之前 版本日志同步采用每條日志同步及每條日志寫入外置數(shù)據(jù)中心mysql的方式缺陷：同步速度慢，每天同步的日志大約2000w條左右，日志量比較大的客戶，經(jīng)常出現(xiàn)日志同步速度跟不上日志產(chǎn)生速度，同步滯后。 3.2版本數(shù)據(jù)采用新的同步機制，內置數(shù)據(jù)中心每隔5分鐘生成一個日志文件，

9、日志同步時，直接將日志文件同步到外置數(shù)據(jù)中心，然后由我們的load程序批量load到數(shù)據(jù)庫。優(yōu)點：大大提高 了同步效率，高端設備一天支持6000w的日志同步，處理了同步速度慢的問題。1、對比之前版本.上圖為日志同步的整體過程， 同步過程中涉及三種表，配置表，日志表和附件 ，同步的先后順序為：配置表日志表附件2、日志同步整體流程.這里所說的配置表，指的是用戶表，組織架構表及運用表等，如左圖。2.1、配置表同步.2.1、配置表同步續(xù) 配置表的同步由同步客戶端程序datasync將配置表同步至外置數(shù)據(jù)中心，然后由外置數(shù)據(jù)中心效力端程序調 用load導入器，將配置表導入至mysql，完成配置表同步。每

10、次啟動同步都會進展配置表的同步，同步前先檢驗各配置表的md5值，假設md5不一樣，那么以為配置表發(fā)生改動，需求進展同步。.2.1、配置表同步續(xù)配置表md5網(wǎng)關序號load.2.2、日志表同步日志表指的是用戶上網(wǎng)產(chǎn)生的真實日志，包括 A ，U， P， M， C， O， I， S， F， Q， T這些表。日志表的同步過程如下：.2.2、日志表同步續(xù).aclog把實時日志寫進日志文件sync_file下，如以下圖：日志文件的命名規(guī)那么如下:例20211130_1515_5F86F7A5_Q.dat，20211130為日期，1515為時間，5F86F7A5網(wǎng)關序號，Q表的命名，從圖中可以看出日志文件是

11、每隔5分鐘生成一次.2.2、日志表同步續(xù).同步客戶端直接從日志文件sync_file中讀取日志文件并同步至外置數(shù)據(jù)中心，同步順序為：A -U- P- M- C- O- I- S- F- Q- T.外置數(shù)據(jù)同時調用load導入器將已同步過來的日志表導入至數(shù)據(jù)庫。外置數(shù)據(jù)中心日志表同步如以下圖：.2.3、附件同步 完成當前5分鐘日志表的同步后，需求進展當前5分鐘附件的同步，直接由同步器將當前5分鐘內的附件打包，同步至外置數(shù)據(jù)中心進展解包，便完成該5分鐘附件的同步。外置數(shù)據(jù)中心附件同步日志如以下圖：附件在內置數(shù)據(jù)中心打包成20211209_1530_5F86F7A5_X.dat這種方式進展同步。.

12、外置數(shù)據(jù)中心同樣具有l(wèi)oad和recover機制，原理和內置數(shù)據(jù)中心一樣，差別的是，內置數(shù)據(jù)中心load和recover不斷在運轉，而外置的load和recover只是在需求的時候才調用，如以下圖：3、外置數(shù)據(jù)中心日志導入及恢復功能.3.1.Datacenter同步完成sync_file之后，會調用Loader.exe。3.2.Loader.exe把sync_file文件中相關日志，導入到MYSQL數(shù)據(jù)庫中。導入勝利后，Loader.exe程序退出任務，等待下一次datacenter對其進展調用。3.3.假設Loader在導入數(shù)據(jù)庫表的時候出現(xiàn)錯誤，并且進展簡單的repair還無法修復，那么調

13、用 Recover.exe進展修復 。3.4.Recover.exe被調用起來后，把無法修復的表進展drop，drop完之后，再從sync_file里面，把對面的表進展恢復。假設勝利，那么把控制權交還給Loader，并退出。3.5.假設Recover失敗超越三次，剛前往給Loader相關錯誤信息，然后退出。3、外置數(shù)據(jù)中心日志導入及恢復功能續(xù).4、緊縮算法同步日志運用緊縮算法： LZO和LZMA，默許是LZO，運用LZMA緊縮算法可以在界面上配置，可以將緊縮比率提高1倍，但是同步時間并不一定會會由于緊縮比率添加而縮短，由于緊縮也會占用較長的時間了。留意：啟用該算法有能夠比不啟用該算法更慢，由于

14、緊縮比較耗時，也在內網(wǎng)環(huán)境下不建議運用。在帶寬缺乏的情況下，如經(jīng)過vpn，多個分支向總部同步日志，可以啟用。.5.1、內置到外置數(shù)據(jù)中心同步，每次傳五分鐘的sync_file內容和五分鐘相關的附件。傳輸完成后，外置數(shù)據(jù)中心，立刻調用導入器(Loader)對日志文件進展導入。5.2、同步日志的順序為配置表-日志表-附件，其中日志表的同步順序為， A -U- P- M- C- O- I- S- F- Q- T5.3、LZMA算法，緊縮比雖然提高 ，但是同步速度不一定提高。建議內網(wǎng)環(huán)境不啟用，帶寬缺乏時再啟用。5.4、內置數(shù)據(jù)中心Loader過的日志文件(load_file)會被刪除，而外置數(shù)據(jù)中心

15、Loader過的日志文件不會被刪除。5.5、Recover只能修復當天的數(shù)據(jù)庫，無法修復整個數(shù)據(jù)庫。5.6、sync_file中的日志文件刪除機制同數(shù)據(jù)庫日志刪除機制5、日志同步總結.培訓內容培訓目的中間表能在進行日志統(tǒng)計，報表生成時合理利用中間表，以提高速度四、中間表. 隨著審計日志量的添加，數(shù)據(jù)中心查詢、統(tǒng)計、生成報表等速度越來越慢，為了滿足客戶運用數(shù)據(jù)中心可以在短時間內呼應并給出結果的需求，提出中間表的實現(xiàn)機制。中間表由后臺程序midtable實現(xiàn)，將原始表中具有求和意義的字段流量，時間，行為等按組、用戶、IP、運用類型及詳細運用做二次統(tǒng)計，一定程度上提高查詢、統(tǒng)計的頁面呼應。1、為什么

16、要引入中間表. 3.0之前的中間表直接從數(shù)據(jù)庫中讀取日志，每半個小時作為一個時間段，生成中間表。中間表運用有限，假設要統(tǒng)計四個小時的流量，那么需求查詢8次中間表。 3.2版本較之前版本發(fā)生了變化，生成中間表的原始數(shù)據(jù)不是從數(shù)據(jù)庫中讀取，直接從sync_file下的文件中讀取，另外也不僅僅是取半個小時內置的數(shù)據(jù)生成中間表，可以取半個小時，一個小時，4個小時內的數(shù)據(jù)生成相應的中間表，這樣要統(tǒng)計四個小時內的流量，只需求查詢一次中間表即可，提高了統(tǒng)計的速度2、對比之前版本. 3.2版本中間表程序會讀取sync_file下的日志文件生成A、F、T、U四種原始表的中間表。不同類型日志的中間表有不同的時間段

17、，如下，中間表一覽：3、中間表一覽.中間表命名規(guī)那么：如： MidFGA1H20211026 其中Mid表示該表為中間表，F(xiàn)表示該表為流量表的中間表，GA分別表示“組和“詳細運用，1H表示中間表為一張1小時的中間表，20211026表示中間表的生成時間。結合前面的中間表一覽，假設需求統(tǒng)計某個用戶13：00至17：00這段時間的流量情況，需求查幾次中間表？3、中間表一覽續(xù).培訓內容培訓目的日志精簡了解日志精簡對哪些應用做了精簡。五、日志精簡.其他運用：一樣源IP、目的IP, 5min記一次P2P：一樣源IP, 5min記一次游戲/炒股：一樣源IP、詳細運用, 10min記一次回絕日志：一樣源IP

18、、詳細運用、域名, 10min記一次PS：優(yōu)化日志記錄也做了一些小修正從原來的5S記錄一次添加到30S一次。1、日志精簡方案由于其它運用，p2p及回絕類的較多，現(xiàn)采用了以下日志精簡方案.2、日志精簡設置.六、晉級及本卷須知培訓內容培訓目的升級及注意事項能說出從低版本升級上來，有哪些注意事項.1、晉級之前最好將之前的日志同步一下，否那么晉級后日志就不會同步了。 由于晉級之后，同步文件只存在于sync_file文件里面，而老的數(shù)據(jù)照舊存在于mysql數(shù)據(jù)庫里。所以假設晉級前沒有同步到外置數(shù)據(jù)中心的數(shù)據(jù)，將不再被同步。但是內置照舊可以查到相關的日志記錄。2、從低版本如3.0版本晉級到3.2，必需運用update5.0版本晉級客戶端。并且要開啟晉級授權序列號，才干進展晉級。運用update4.0