說說最近的一個(gè)案例吧，線上阿里云RDS上的一個(gè)游戲日志庫最近出現(xiàn)了一點(diǎn)問題，隨著游戲人數(shù)的增加，在線日志庫的數(shù)據(jù)量越來越大，最新的日志庫都已經(jīng)到50G大小了，在線變更的時(shí)間非常長。

    之前之所以沒有發(fā)現(xiàn)，是因?yàn)橹耙恢睕]有進(jìn)行過日志庫的變更，但是隨著業(yè)務(wù)的深入，需要增加一些游戲?qū)傩裕獙χ暗娜罩編爝M(jìn)行變更，這樣一來，長時(shí)間的維護(hù)窗口讓業(yè)務(wù)方和DBA都望而卻步，日志優(yōu)化迫在眉睫。

    首先看日志庫的情況：

1、日志庫中數(shù)據(jù)量大于5000w的大表有5張；

2、這5張表開量前每個(gè)月的數(shù)據(jù)量大概在2000w左右，開量后會(huì)更多；

3、有2個(gè)表的索引大小已經(jīng)超過數(shù)據(jù)文件大小

    詢問了業(yè)務(wù)方和運(yùn)營對這些表的要求，具體如下：

1、保留最近這3個(gè)月的數(shù)據(jù)，其他的數(shù)據(jù)可以進(jìn)行流轉(zhuǎn)，避免影響線上業(yè)務(wù)的性能。

2、3個(gè)月之前的數(shù)據(jù)流轉(zhuǎn)到一個(gè)本地庫中，可以支持查詢即可，查詢速度不能過于慢，分鐘級別的可以接受。

3、日志庫在遷移的過程中，能夠容忍幾分鐘的表數(shù)據(jù)丟失，對數(shù)據(jù)的同步實(shí)時(shí)性要求不是很高

4、線上的日志庫需要支持用戶活躍度等統(tǒng)計(jì)

5、不希望執(zhí)行分庫分表，有很多查詢近幾個(gè)月的SQL操作，表之間存在一定的耦合性，分表之后不利于關(guān)聯(lián)操作

    基于上面的分析，結(jié)合實(shí)際情況，初步設(shè)想的方案是：

1、對線上數(shù)據(jù)庫game_log中的表進(jìn)行rename操作，然后將原來的表重新創(chuàng)建出來，這個(gè)過程中不是連續(xù)的，可能會(huì)丟失幾秒鐘的數(shù)據(jù)。具體的操作如下：

#第一步
rename table game_log.table to game_log_bak.table;

#第二步，獲取表結(jié)構(gòu)，其中重要的是auto_increment的值，
#保證后續(xù)導(dǎo)入三個(gè)月內(nèi)數(shù)據(jù)的時(shí)候不會(huì)發(fā)生沖突
show create table game_log_bak.table\G

#第三步
在game_log庫中重新創(chuàng)建第二步的表結(jié)構(gòu)

2、將rename過后的game_log_bak庫中的數(shù)據(jù)流轉(zhuǎn)到本地的離線數(shù)據(jù)庫中，該數(shù)據(jù)庫采用infobright存儲(chǔ)引擎，這樣能夠支持離線數(shù)據(jù)的快速查詢

3、備份并清理線上表3個(gè)月之外的數(shù)據(jù)，大概是40G，并將線上的game_log_bak數(shù)據(jù)庫中3個(gè)月以內(nèi)的數(shù)據(jù)（大概10G）重新灌入game_log數(shù)據(jù)庫中，這樣結(jié)構(gòu)就變成了：

4、刪除game_log_bak庫，并搭建一個(gè)只讀從庫，實(shí)時(shí)的從主庫上同步game_log庫的信息，如下：

5、從本地的只讀從庫中，像本地的infobright數(shù)據(jù)庫中同步數(shù)據(jù)，同步的方法可以選用dataX工具，像下面這樣：

6、設(shè)置定時(shí)任務(wù)，按照一定的周期清理線上的過期數(shù)據(jù)，確保線上只保留最近3個(gè)月的數(shù)據(jù)，不會(huì)對rds的磁盤存儲(chǔ)空間產(chǎn)生壓力。

    這個(gè)方法中，目前看來存在下面幾個(gè)問題：

1、經(jīng)常性的清理線上數(shù)據(jù)，這些數(shù)據(jù)占用的表空間不能被立即回收，可能會(huì)造成數(shù)據(jù)表的碎片問題。

2、后續(xù)如果游戲的量級上來之后，使用這個(gè)問題可能還是會(huì)有問題，屆時(shí)可以適當(dāng)調(diào)整日志表的清理周期，如果數(shù)據(jù)量過大，可以考慮其他的方案來處理。

   回過頭來分析，表的設(shè)計(jì)上還是存在一定的問題，日志表中記錄的應(yīng)該只是流水?dāng)?shù)據(jù)，盡量不能出現(xiàn)關(guān)聯(lián)查詢的情況，或者說可以提前評估數(shù)據(jù)量，然后使用季度表或者月表來處理這種的大量的日志情況，這樣在清理和維護(hù)的時(shí)候可能就方便的多。

以上就是MySQL 線上日志庫遷移實(shí)例的詳細(xì)內(nèi)容，更多關(guān)于MySQL 線上日志庫遷移的資料請關(guān)注腳本之家其它相關(guān)文章！