由于歷史業(yè)務(wù)數(shù)據(jù)采用mysql來(lái)存儲(chǔ)的,其中有一張操作記錄表video_log,每當(dāng)用戶創(chuàng)建、更新或者審核人員審核的時(shí)候,對(duì)應(yīng)的video_log就會(huì)加一條日志,這個(gè)log表只有insert,可想而知,1個(gè)video對(duì)應(yīng)多條log,一天10w video,平均統(tǒng)計(jì)一個(gè)video對(duì)應(yīng)5條log,那么一天50w的log, 一個(gè)月50 * 30 = 1500w條記錄, 一年就是1500 * 12 = 1.8億。目前線上已經(jīng)有2億多的數(shù)據(jù)了,由于log本身不面向C端,用于查詢問(wèn)題的,所以可以忍受一點(diǎn)的延遲。 但是隨著時(shí)間的積累,必然會(huì)越來(lái)越慢,影響效率,于是提出改造。
由于log本身不是最關(guān)鍵的數(shù)據(jù),但是也要求實(shí)時(shí)性高(用于實(shí)時(shí)查詢問(wèn)題),所以一開(kāi)始的想法是核心的基礎(chǔ)存儲(chǔ)還是保持不變,較老的數(shù)據(jù)遷移出去,畢竟突然去查詢一年前的操作記錄的概率很小,如果突然要查,可以走離線。設(shè)計(jì)的話,我們只需要一個(gè)定時(shí)腳本,每天在凌晨4點(diǎn)左右(業(yè)務(wù)低峰期)抽數(shù)據(jù)。抽出的數(shù)據(jù)可以上報(bào)到一些離線存儲(chǔ)(一般公司都有基于hive的數(shù)倉(cāng)之類(lèi)的),這樣就可以保持線上的video_log的數(shù)據(jù)不會(huì)一直增長(zhǎng)。
分表也是一種解決方案,相對(duì)方案一的好處就是,所有的數(shù)據(jù)都支持實(shí)時(shí)查,缺點(diǎn)是代碼要改造了。
接下來(lái)就是改造代碼了,得解決新老數(shù)據(jù)讀寫(xiě)的問(wèn)題。
方案二的缺點(diǎn)比較明顯,3年后咋辦,繼續(xù)拆表?感覺(jué)始終有個(gè)歷史債在那。于是我們的目光定位到了tidb,tidb是分布式的數(shù)據(jù)庫(kù),接入了tidb,我們就無(wú)需關(guān)心分表了,這些tidb都幫我們做了,它會(huì)自己做節(jié)點(diǎn)的擴(kuò)容。由于是分布式的,所以tidb的主鍵是無(wú)序的,這點(diǎn)很重要。
整個(gè)流程大概分為以下4個(gè)步驟:
遷移至tidb,看似很簡(jiǎn)單,其實(shí)在job腳本這里隱藏著幾個(gè)坑。
綜合考慮數(shù)據(jù)的重復(fù)性,job重啟效率性,和整個(gè)同步的效率性,我大概做出以下方案:
最終通過(guò)方案三的四個(gè)切換步驟+高效率的同步腳本平穩(wěn)的完成了數(shù)據(jù)的遷移
到此這篇關(guān)于mysql遷移的方案與踩坑的文章就介紹到這了,更多相關(guān)mysql遷移方案與踩坑內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
標(biāo)簽:三明 福州 山西 定西 揚(yáng)州 阿里 無(wú)錫 溫州
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《一次mysql遷移的方案與踩坑實(shí)戰(zhàn)記錄》,本文關(guān)鍵詞 一次,mysql,遷移,的,方案,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。