說說最近的一個案例吧，線上阿里云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 線上日志庫遷移的資料請關注腳本之家其它相關文章！