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

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

首先看日志庫的情況：

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

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

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

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

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

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

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

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

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

基于上面的分析，結合實際情況，初步設想的方案是：

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

#第一步rename table game_log.table to game_log_bak.table;#第二步，獲取表結構，其中重要的是auto_increment的值，#保證后續(xù)導入三個月內(nèi)數(shù)據(jù)的時候不會發(fā)生沖突show create table game_log_bak.tableG#第三步在game_log庫中重新創(chuàng)建第二步的表結構

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

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

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

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

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

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

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

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

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

以上就是MySQL 線上日志庫遷移實例的詳細內(nèi)容，更多關于MySQL 線上日志庫遷移的資料請關注好吧啦網(wǎng)其它相關文章！