mysql遷移方案有哪些

mysql遷移方案有哪些，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

方案一：老數據備份

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

方案二：分表

分表也是一種解決方案，相對方案一的好處就是，所有的數據都支持實時查，缺點是代碼要改造了。

• 首先確認sharding key，因為video_log是和video綁定的，所以自然而然選擇video_id作為我們的sharding key

• 按什么分表確定了，接下來確認下分多少張表。先定個小目標，支撐3年。每張表最大數據量為1個億（由于我們的查詢簡單），按照上面的統計，我們3年大概：3*1.8=5.4億，那么大概需要5.4/1≈6張表。

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

• 新數據的插入直接插入新表

• 由于log表只有insert，所以不存在update、delete這些操作，不需要考慮這些場景。

• 分表后，一個video的log存在兩張表（老表和新表），所以臨時兩張表都查，然后做個合并

• 同步老數據到新表中

• 下線讀取老表的代碼

方案三：遷移至tidb

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

1. 先雙寫（記錄下剛開始雙寫時的mysql的id，在此id前的肯定都是老數據）

2. 同步老數據（通過第一步記錄的id來區分）

3. 切讀（老數據同步完了）

4. 下雙寫

重點說下同步老數據遇到的坑

遷移至tidb，看似很簡單，其實在job腳本這里隱藏著幾個坑。

• 要考慮萬一job中途斷了，重新啟動咋辦，撇開重頭跑數據的時間成本，已經同步的數據重新跑會重復，還要考慮重復數據的問題。解決重復數據的問題，可以對老表新加一個字段標識是否已同步，每次同步完，更新下字段。缺點：線上數據大，加個字段不太安全，可能造成線上阻塞。

• 既然加個字段不好，那就用現有的主鍵id做約束，把主鍵id也同步過去，這樣就算腳本重啟，從頭開始跑的，也因為相同的主健已經插入過，那么就會報錯跳過。看似很完美，然而tidb是分布式的，主鍵id不是連續的，那么可能出現這樣一種情況。正常的業務數據插入tidb，tidb分配的主鍵id和mysql同步的主鍵id重復，那么不管是誰，最后插入的那一條肯定是失敗的。

最終同步腳本方案

綜合考慮數據的重復性，job重啟效率性，和整個同步的效率性，我大概做出以下方案：

1. 任務分批提升效率：首先根據處理能力和預期完成時間，先對老數據進行分批，大概分了10批，10個job去跑不同批次的數據，互不干擾，且每次批量更新100條。

2. 記錄狀態，重啟自動恢復到斷點：每次同步數據后記錄下當前同步的位置（redis記錄下當前的id），就算重啟也可以從redis里拿到之前的更新位置，接著更新。

3. 避免主鍵沖突：同步除了主鍵之外的所有字段（不同步主鍵）

最終通過方案三的四個切換步驟+高效率的同步腳本平穩的完成了數據的遷移

關于mysql遷移方案有哪些問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。