最近一段時間碰到一些數(shù)據(jù)遷移的項目，如：Oracle遷移到MySQL，MsSQL遷移到MySQL，云MySQL遷移到本地MySQL。對于這方面做了系統(tǒng)的整理。包括：遷移方案的選擇、如何跳出遷移遇到的坑、怎樣修改MySQL參數(shù)獲取最大性能，加入分庫分表的需求如何實現(xiàn)？文章的最后，作者做了很多可行性的總結(jié)，碼字不易，如果對您有幫助，感謝轉(zhuǎn)發(fā)。

遷移方案的選擇：

拋開業(yè)務(wù)邏輯的因素，根據(jù)不同的版本、不同平臺、不同停機時間需求，有不同的可選路徑?jīng)Q定遷移方

法和工具：

遷移方法優(yōu)點缺點

SQL LOAD操作簡單、速度快、選擇數(shù)據(jù)范圍靈活需自定義開發(fā)批量操作、對于CLOB等特殊字段無法支持

OGG商用軟件，廣泛的數(shù)據(jù)庫平臺支持、靈活的復(fù)制架構(gòu)、基于日志的實時數(shù)據(jù)同步、穩(wěn)定性高對維護技能有一定的要求、費用高

ETL 軟件使用方便簡單、定時同步批量處理大量表需定制化配置

MYSQL移植工具安裝簡單、可自動創(chuàng)建表不可定制、技術(shù)支持較弱

定制遷移工具可高度定制，保證最佳性能和最短停機時間暫無

由于不同的數(shù)據(jù)庫版本、不同的組件安裝、不同的應(yīng)用開發(fā)特征都會導(dǎo)致遷移計劃的復(fù)雜性和差異性。

調(diào)研中，除了OGG，有幾個MySQL遷移的工具，推薦的比較多，但是收費的。

【工具：OGG (goldengate)

同時支持Oracle，Mssql 遷移到 MySQL 上

參數(shù)：filter，COMPUTE 進行分庫分表邏輯】

● SQLyog

(https://www.webyog.com/product/sqlyog)

● Navicat Premium

(https://www.navicat.com/products/navicat-premium)

● Mss2sql

(http://www.convert-in.com/)

● DB2DB

(http://www.szmesoft.com/DB2DB)

選擇遷移軟件，必須要考慮 軟件易用性， 處理速度和內(nèi)存占用，數(shù)據(jù)完整性。這部分很重要。

以上四款軟件中：

1. 最不推薦使用的是 Navicat Premium，主要原因是數(shù)據(jù)的完整性表現(xiàn)較差，轉(zhuǎn)換后的數(shù)

據(jù)不能立即用于生產(chǎn)環(huán)境，需要程序員仔細自行查找原因和分析。

2. SQLyog 有較好的數(shù)據(jù)完整性，但整體處理速度非常的慢，如果數(shù)據(jù)較大的情況下，需要浪費非常多寶

貴的時間。比較推薦的是

3. DB2DB，處理速度，數(shù)據(jù)完整性，整體表現(xiàn)較好，操作起來實在方便。

我本人趨向于自己寫python腳本。

遷移中會存在哪些細節(jié)上的問題？

1. 字符集

字符集轉(zhuǎn)化：Oracle字符集AL32UTF8，ZHS16GBK，轉(zhuǎn)換成MySQL支持的字符集Latin1，utf8，utf8mb4(emoji的表情符)

Mysql對于字符集里有兩個概念：一個是”Character set”另一個是”Collations”。

Collations：Mysql對字符的比較，排序規(guī)則

Character set：字符的編碼方式

2. 字段類型

Oracle Row， Clob，BINARY_DOUBLE類型轉(zhuǎn)化成MySQL支持的字段類型。

如：Oracle CLOB字段最大長度4G對應(yīng)MySQL LONGTEXT 等等，但要是把數(shù)據(jù)這些數(shù)據(jù)遷移到MySQL上，可以想象到會發(fā)生什么事情。

3. 主鍵

有些源表沒有設(shè)置主鍵， 但對于MySQL來說主鍵的意思非常大，特別是復(fù)制環(huán)節(jié)里。

4. 遷移時間和數(shù)據(jù)量

對于現(xiàn)在在線不間斷提供的業(yè)務(wù)非常重要，按照這個指標可以制定全量或者增量方式進行遷移。

5. 考慮因素

除了以上內(nèi)容源數(shù)據(jù)庫還有賬號、視圖、存儲過程、函數(shù)、觸發(fā)器，索引等，同樣也很重要，都是需要考慮的一個因素。

6. 校驗數(shù)據(jù)

這一關(guān)最后門卡，當數(shù)據(jù)遷移完成后，如何確保數(shù)據(jù)的正確遷移、沒有遺漏和錯誤是一個很難的問題。這里的難不是實現(xiàn)起來困難，而是要把它自動化，達到節(jié)省人力的目標有點難，因為兩者的數(shù)據(jù)類型不同，數(shù)據(jù)量偏大，寫一些腳本去做檢查效果不大。

數(shù)據(jù)的完整性驗證是十分重要的，千萬不要怕驗證到錯誤后要花好長時候去抽取同步的操作這一步。因為一旦沒有驗證到錯誤，讓數(shù)據(jù)進行了使用卻亂掉了，后果將更嚴重。

一般場景下都是對應(yīng)查詢數(shù)據(jù)行數(shù)count來判斷數(shù)據(jù)的是否存在問題。或則 是用create_time時間字段進行驗證數(shù)據(jù)。或則抽取部分數(shù)據(jù)進行驗證。還有導(dǎo)入過程中的log和警告 ，errors 等信息。

MySQL一些性能參數(shù)

可以在導(dǎo)入數(shù)據(jù)的時候預(yù)先修改一些參數(shù)，來獲取最大性能的處理，比如可以把自適應(yīng)hash關(guān)掉，Doublewrite關(guān)掉，然后調(diào)整緩存區(qū)，log文件的大小，把能變大的都變大，把能關(guān)的都關(guān)掉來獲取最大的性能，接下來說幾個常用的：

1. innodb_flush_log_at_trx_commit

如果innodb_flush_log_at_trx_commit設(shè)置為0，log buffer將每秒一次地寫入log file中，并且log file的flush(刷到磁盤)操作同時進行。該模式下，在事務(wù)提交時，不會主動觸發(fā)寫入磁盤的操作。

如果innodb_flush_log_at_trx_commit設(shè)置為1，每次事務(wù)提交時MySQL都會把log buffer的數(shù)據(jù)寫入log file，并且flush(刷到磁盤)中去。

如果innodb_flush_log_at_trx_commit設(shè)置為2，每次事務(wù)提交時MySQL都會把log buffer的數(shù)據(jù)寫入log file。但是flush(刷到磁盤)的操作并不會同時進行。該模式下，MySQL會每秒執(zhí)行一次 flush(刷到磁盤)操作。

注意：由于進程調(diào)度策略問題,這個“每秒執(zhí)行一次 flush(刷到磁盤)操作”并不是保證100%的“每秒”。

2. sync_binlog

sync_binlog 的默認值是0，像操作系統(tǒng)刷其它文件的機制一樣，MySQL不會同步到磁盤中去，而是依賴操作系統(tǒng)來刷新binary log。

當sync_binlog =N (N>0) ，MySQL 在每寫N次 二進制日志binary log時，會使用fdatasync()函數(shù)將它的寫二進制日志binary log同步到磁盤中去。

注意：如果啟用了autocommit，那么每一個語句statement就會有一次寫操作；否則每個事務(wù)對應(yīng)一個寫操作。

3. max_allowed_packet

在導(dǎo)大容量數(shù)據(jù)特別是CLOB數(shù)據(jù)時，可能會出現(xiàn)異常：“Packets larger than max_allowed_packet are not allowed”。這是由于MySQL數(shù)據(jù)庫有一個系統(tǒng)參數(shù)max_allowed_packet，其默認值為1048576(1M)，可以通過如下語句在數(shù)據(jù)庫中查詢其值：show VARIABLES like ‘%max_allowed_packet%’;

修改此參數(shù)的方法是在MySQL文件夾找到my.cnf文件，在my.cnf文件[MySQLd]中添加一行：max_allowed_packet=16777216

4. innodb_log_file_size

InnoDB日志文件太大，會影響MySQL崩潰恢復(fù)的時間，太小會增加IO負擔，所以我們要調(diào)整合適的日志大小。在數(shù)據(jù)導(dǎo)入時先把這個值調(diào)大一點。避免無謂的buffer pool的flush操作。但也不能把innodb_log_file_size開得太大，會明顯增加 InnoDB的log寫入操作，而且會造成操作系統(tǒng)需要更多的Disk Cache開銷。

5. innodb_log_buffer_size

InnoDB用于將日志文件寫入磁盤時的緩沖區(qū)大小字節(jié)數(shù)。為了實現(xiàn)較高寫入吞吐率，可增大該參數(shù)的默認值。一個大的log buffer讓一個大的事務(wù)運行，不需要在事務(wù)提交前寫日志到磁盤，因此，如果你有事務(wù)比如update、insert或者delete 很多的記錄，讓log buffer 足夠大來節(jié)約磁盤I/O。

6. innodb_buffer_pool_size

這個參數(shù)主要緩存InnoDB表的索引、數(shù)據(jù)、插入數(shù)據(jù)時的緩沖。為InnoDN加速優(yōu)化首要參數(shù)。一般讓它等于你所有的innodb_log_buffer_size的大小就可以，innodb_log_file_size要越大越好。

7. innodb_buffer_pool_instances

InnoDB緩沖池拆分成的區(qū)域數(shù)量。對于數(shù)GB規(guī)模緩沖池的系統(tǒng)，通過減少不同線程讀寫緩沖頁面的爭用，將緩沖池拆分為不同實例有助于改善并發(fā)性。

分庫分表方案

現(xiàn)在加難度加入分庫分表需求。

這種情況建議選擇傳統(tǒng)的方式寫一個遷移程序，讀源數(shù)據(jù)庫，通過中間件寫入目標庫db1,db2,db3里

如果源數(shù)據(jù)源設(shè)計的合理完全可以用全量+增量方式實現(xiàn)。如下圖所示

雖然這種方式很靈活，自行控制，但也有缺點，所有業(yè)務(wù)邏輯，分庫分表方案，驗證都需要手動編寫

下次可以在不同的平臺下使用。

現(xiàn)在業(yè)界比較常用的分庫分表的中間件有兩種：

proxy形，如：基于阿里開源的Cobar產(chǎn)品而研發(fā)的mycat， 需要部署另外服務(wù)器，作為分庫分表的代理，對外服務(wù)，包含分庫分表的配置信息，現(xiàn)在版本是mycat2.0。

client形式，如當當出的sharding-jdbc，現(xiàn)在有京東金融進行維護，現(xiàn)在版本sharding-jdbc4.0開發(fā)中。是jar包，使用非常方便。我個人趨向于Sharding-JDBC，這種方式，無需額外部署，替換原有jdbc，DBA也無需改變原有的運維方式，減輕了DBA的任務(wù)。

總結(jié)

1. 一定要選擇合適你的遷移工具，沒有哪一個工具是最好的。

2. 數(shù)據(jù)的檢驗非常重要，有的時候我們遷過去很開心，校驗時發(fā)生錯誤，這個時候必須要重來。

3. 重復(fù)地遷移是很正常的，合乎每次遷移可能需要很長時間，總會是有錯誤的，要做好再遷的心態(tài)。

4. 遷移過程中的日志記錄非常重要，一段出現(xiàn)故障，可以再問題點開始繼續(xù)進行遷移。

本文由 數(shù)據(jù)和云 發(fā)布在 ITPUB，轉(zhuǎn)載此文請保持文章完整性，并請附上文章來源(ITPUB)及本頁鏈接。

原文鏈接：http://www.itpub.net/2019/05/20/1910/

總結(jié)

以上是生活随笔為你收集整理的oracle mysql迁移方案_Oracle/云MySQL/MsSQL“大迁移”真相及最优方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。