背景

由于歷史業(yè)務(wù)數(shù)據(jù)采用mysql來存儲(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端，用于查詢問題的，所以可以忍受一點(diǎn)的延遲。 但是隨著時(shí)間的積累，必然會(huì)越來越慢，影響效率，于是提出改造。

方案一：老數(shù)據(jù)備份

由于log本身不是最關(guān)鍵的數(shù)據(jù)，但是也要求實(shí)時(shí)性高（用于實(shí)時(shí)查詢問題），所以一開始的想法是核心的基礎(chǔ)存儲(chǔ)還是保持不變，較老的數(shù)據(jù)遷移出去，畢竟突然去查詢一年前的操作記錄的概率很小，如果突然要查，可以走離線。設(shè)計(jì)的話，我們只需要一個(gè)定時(shí)腳本，每天在凌晨4點(diǎn)左右（業(yè)務(wù)低峰期）抽數(shù)據(jù)。抽出的數(shù)據(jù)可以上報(bào)到一些離線存儲(chǔ)（一般公司都有基于hive的數(shù)倉之類的）,這樣就可以保持線上的video_log的數(shù)據(jù)不會(huì)一直增長。

方案二：分表

分表也是一種解決方案，相對(duì)方案一的好處就是，所有的數(shù)據(jù)都支持實(shí)時(shí)查，缺點(diǎn)是代碼要改造了。

• 首先確認(rèn)sharding key，因?yàn)関ideo_log是和video綁定的，所以自然而然選擇video_id作為我們的sharding key
• 按什么分表確定了，接下來確認(rèn)下分多少張表。先定個(gè)小目標(biāo)，支撐3年。每張表最大數(shù)據(jù)量為1個(gè)億（由于我們的查詢簡(jiǎn)單），按照上面的統(tǒng)計(jì)，我們3年大概：3*1.8=5.4億，那么大概需要5.4/1≈6張表。

接下來就是改造代碼了，得解決新老數(shù)據(jù)讀寫的問題。

• 新數(shù)據(jù)的插入直接插入新表
• 由于log表只有insert，所以不存在update、delete這些操作，不需要考慮這些場(chǎng)景。
• 分表后，一個(gè)video的log存在兩張表（老表和新表），所以臨時(shí)兩張表都查，然后做個(gè)合并
• 同步老數(shù)據(jù)到新表中
• 下線讀取老表的代碼

方案三：遷移至tidb

方案二的缺點(diǎn)比較明顯，3年后咋辦，繼續(xù)拆表？感覺始終有個(gè)歷史債在那。于是我們的目光定位到了tidb，tidb是分布式的數(shù)據(jù)庫，接入了tidb，我們就無需關(guān)心分表了，這些tidb都幫我們做了，它會(huì)自己做節(jié)點(diǎn)的擴(kuò)容。由于是分布式的，所以tidb的主鍵是無序的，這點(diǎn)很重要。
整個(gè)流程大概分為以下4個(gè)步驟：

1. 先雙寫（記錄下剛開始雙寫時(shí)的mysql的id，在此id前的肯定都是老數(shù)據(jù)）
2. 同步老數(shù)據(jù)（通過第一步記錄的id來區(qū)分）
3. 切讀（老數(shù)據(jù)同步完了）
4. 下雙寫

重點(diǎn)說下同步老數(shù)據(jù)遇到的坑

遷移至tidb，看似很簡(jiǎn)單，其實(shí)在job腳本這里隱藏著幾個(gè)坑。

• 要考慮萬一job中途斷了，重新啟動(dòng)咋辦，撇開重頭跑數(shù)據(jù)的時(shí)間成本，已經(jīng)同步的數(shù)據(jù)重新跑會(huì)重復(fù)，還要考慮重復(fù)數(shù)據(jù)的問題。解決重復(fù)數(shù)據(jù)的問題，可以對(duì)老表新加一個(gè)字段標(biāo)識(shí)是否已同步，每次同步完，更新下字段。缺點(diǎn)：線上數(shù)據(jù)大，加個(gè)字段不太安全，可能造成線上阻塞。
• 既然加個(gè)字段不好，那就用現(xiàn)有的主鍵id做約束，把主鍵id也同步過去，這樣就算腳本重啟，從頭開始跑的，也因?yàn)橄嗤闹鹘∫呀?jīng)插入過，那么就會(huì)報(bào)錯(cuò)跳過。看似很完美，然而tidb是分布式的，主鍵id不是連續(xù)的，那么可能出現(xiàn)這樣一種情況。正常的業(yè)務(wù)數(shù)據(jù)插入tidb，tidb分配的主鍵id和mysql同步的主鍵id重復(fù)，那么不管是誰，最后插入的那一條肯定是失敗的。

最終同步腳本方案

綜合考慮數(shù)據(jù)的重復(fù)性，job重啟效率性，和整個(gè)同步的效率性，我大概做出以下方案：

1. 任務(wù)分批提升效率：首先根據(jù)處理能力和預(yù)期完成時(shí)間，先對(duì)老數(shù)據(jù)進(jìn)行分批，大概分了10批，10個(gè)job去跑不同批次的數(shù)據(jù)，互不干擾，且每次批量更新100條。
2. 記錄狀態(tài)，重啟自動(dòng)恢復(fù)到斷點(diǎn)：每次同步數(shù)據(jù)后記錄下當(dāng)前同步的位置（redis記錄下當(dāng)前的id），就算重啟也可以從redis里拿到之前的更新位置，接著更新。
3. 避免主鍵沖突：同步除了主鍵之外的所有字段（不同步主鍵）

最終通過方案三的四個(gè)切換步驟+高效率的同步腳本平穩(wěn)的完成了數(shù)據(jù)的遷移

總結(jié)

到此這篇關(guān)于mysql遷移的方案與踩坑的文章就介紹到這了,更多相關(guān)mysql遷移方案與踩坑內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！