原文：http://www.enmotech.com/web/detail/1/691/1.html (需打開瀏覽器，方可查看原文 )

---

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

遷移方案的選擇：

拋開業務邏輯的因素，根據不同的版本、不同平臺、不同停機時間需求，有不同的可選路徑決定遷移方法和工具：

由于不同的數據庫版本、不同的組件安裝、不同的應用開發特征都會導致遷移計劃的復雜性和差異性。

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

【工具：OGG (goldengate) 】

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

參數：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)

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

以上四款軟件中：

1. 最不推薦使用的是 Navicat Premium，主要原因是數據的完整性表現較差，轉換后的數

據不能立即用于生產環境，需要程序員仔細自行查找原因和分析。

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

貴的時間。比較推薦的是

3. DB2DB，處理速度，數據完整性，整體表現較好，操作起來實在方便。

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

遷移中會存在哪些細節上的問題？

1. 字符集

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

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

Collations：Mysql對字符的比較，排序規則

Character set：字符的編碼方式

2. 字段類型

Oracle Row， Clob，BINARY_DOUBLE類型轉化成MySQL支持的字段類型。

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

3. 主鍵

有些源表沒有設置主鍵， 但對于MySQL來說主鍵的意思非常大，特別是復制環節里。

4. 遷移時間和數據量

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

5. 考慮因素

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

6. 校驗數據

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

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

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

MySQL一些性能參數

可以在導入數據的時候預先修改一些參數，來獲取最大性能的處理，比如可以把自適應hash關掉，Doublewrite關掉，然后調整緩存區，log文件的大小，把能變大的都變大，把能關的都關掉來獲取最大的性能，接下來說幾個常用的：

1. innodb_flush_log_at_trx_commit

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

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

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

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

2. sync_binlog

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

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

注意：如果啟用了AUTOCOMMIT，那么每一個語句STATEMENT就會有一次寫操作；否則每個事務對應一個寫操作。

3. max_allowed_packet

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

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

4. innodb_log_file_size

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

5. innodb_log_buffer_size

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

6. innodb_buffer_pool_size

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

7. innodb_buffer_pool_instances

InnoDB緩沖池拆分成的區域數量。對于數GB規模緩沖池的系統，通過減少不同線程讀寫緩沖頁面的爭用，將緩沖池拆分為不同實例有助于改善并發性。

分庫分表方案

現在加難度加入分庫分表需求。

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

如果源數據源設計的合理完全可以用全量+增量方式實現。如下圖所示：

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

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

現在業界比較常用的分庫分表的中間件有兩種：

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

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

---

總結

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

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

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

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

---

作者：崔虎龍，云和恩墨-開源架構部-MySQL技術顧問，熟悉金融、游戲、物流等數據中心運營管理的流程、規范以及自動化運維等方面。擅長MySQL，Redis，MongoDB數據庫高可用設計和運維故障處理、備份恢復、升級遷移、性能優化。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。