MySQL 線上日志庫遷移實例

    說說最近的一個案例吧,線上阿裡雲RDS上的一個遊戲日志庫最近出現瞭一點問題,隨著遊戲人數的增加,在線日志庫的數據量越來越大,最新的日志庫都已經到50G大小瞭,在線變更的時間非常長。

    之前之所以沒有發現,是因為之前一直沒有進行過日志庫的變更,但是隨著業務的深入,需要增加一些遊戲屬性,要對之前的日志庫進行變更,這樣一來,長時間的維護窗口讓業務方和DBA都望而卻步,日志優化迫在眉睫。

    首先看日志庫的情況:

1、日志庫中數據量大於5000w的大表有5張;

2、這5張表開量前每個月的數據量大概在2000w左右,開量後會更多;

3、有2個表的索引大小已經超過數據文件大小

    詢問瞭業務方和運營對這些表的要求,具體如下:

1、保留最近這3個月的數據,其他的數據可以進行流轉,避免影響線上業務的性能。

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

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

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

5、不希望執行分庫分表,有很多查詢近幾個月的SQL操作,表之間存在一定的耦合性,分表之後不利於關聯操作

    基於上面的分析,結合實際情況,初步設想的方案是:

1、對線上數據庫game_log中的表進行rename操作,然後將原來的表重新創建出來,這個過程中不是連續的,可能會丟失幾秒鐘的數據。具體的操作如下:

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

#第二步,獲取表結構,其中重要的是auto_increment的值,
#保證後續導入三個月內數據的時候不會發生沖突
show create table game_log_bak.table\G

#第三步
在game_log庫中重新創建第二步的表結構

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

3、備份並清理線上表3個月之外的數據,大概是40G,並將線上的game_log_bak數據庫中3個月以內的數據(大概10G)重新灌入game_log數據庫中,這樣結構就變成瞭:

4、刪除game_log_bak庫,並搭建一個隻讀從庫,實時的從主庫上同步game_log庫的信息,如下:

5、從本地的隻讀從庫中,像本地的infobright數據庫中同步數據,同步的方法可以選用dataX工具,像下面這樣:

6、設置定時任務,按照一定的周期清理線上的過期數據,確保線上隻保留最近3個月的數據,不會對rds的磁盤存儲空間產生壓力。

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

1、經常性的清理線上數據,這些數據占用的表空間不能被立即回收,可能會造成數據表的碎片問題。

2、後續如果遊戲的量級上來之後,使用這個問題可能還是會有問題,屆時可以適當調整日志表的清理周期,如果數據量過大,可以考慮其他的方案來處理。

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

以上就是MySQL 線上日志庫遷移實例的詳細內容,更多關於MySQL 線上日志庫遷移的資料請關註WalkonNet其它相關文章!