主頁 > 知識庫 > MySQL 線上日志庫遷移實例

MySQL 線上日志庫遷移實例

熱門標(biāo)簽:AI電銷 Linux服務(wù)器 呼叫中心市場需求 網(wǎng)站排名優(yōu)化 服務(wù)外包 百度競價排名 地方門戶網(wǎng)站 鐵路電話系統(tǒng)

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

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

    首先看日志庫的情況:

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

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

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

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

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

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

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

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

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

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

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

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

#第二步,獲取表結(jié)構(gòu),其中重要的是auto_increment的值,
#保證后續(xù)導(dǎo)入三個月內(nèi)數(shù)據(jù)的時候不會發(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存儲引擎,這樣能夠支持離線數(shù)據(jù)的快速查詢

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

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

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

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

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

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

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

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

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

您可能感興趣的文章:
  • MySQL導(dǎo)出數(shù)據(jù)遇到secure-file-priv問題的解決方法
  • MySQL 線上數(shù)據(jù)庫清理數(shù)據(jù)的方法
  • mysql創(chuàng)建表添加字段注釋的實現(xiàn)方法
  • MySQL 大表的count()優(yōu)化實現(xiàn)
  • MySQL source命令的使用簡介
  • MySQL too many connections錯誤的原因及解決
  • 解決出現(xiàn)secure_file_priv null的問題

標(biāo)簽:仙桃 衡水 湖南 黃山 銅川 湘潭 蘭州 崇左

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MySQL 線上日志庫遷移實例》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266