OnlineSchemaChange是Facebook開源的在線修改表結構的工具，具體原理這裏不多說了，有興趣的同學可以看下官方文檔:https://github.com/facebookincubator/OnlineSchemaChange/wiki
這裏主要介紹下在遷移的時候使用的情況，首先官網的OSC工具不支持主從同步，當時測試是在單庫上進行測試，而生產環境是有主從的，結果在主庫上直接運行了OSC，可以看到如下的輸出：
可以看到主庫運行基本正常，表結構也正常修改了，並沒有鎖表影響到線上正常業務
發現主從不一致後的排查：
查看binlog事件，看具體是哪個事務導致的主從不一致
對binlog同步出錯的事務sql進行反覆的查看及覈對
根據從庫的狀態可以判斷出是__osc_chg_orders是這個臨時表不存在導致無法同步
隨後找到網上說跳過錯誤事務就可以恢復同步，進行了
slave stop; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; slave start; show slave status\G
進行跳過一個錯誤事務後再次查看，發現每次都卡在沒有這個__osc_chg_orders臨時表
網上查詢到可以忽略某些表的同步，在從庫上可以忽略某些表的同步，在主庫binlog中有大量的臨時表事務，開始我們手動一條一條的跳過，發現並不可行，手動執行50次後發現__osc_chg_orders臨時表的數據可能跟原表的數據量一樣大，也就是1千萬條，這樣我們難道要跳過1千萬個事務，如果直接跳過1kw也事務，也不行，因爲這裏面還有在上線正常執行的事務，這裏發現可以忽略這個表同步，在從庫中設置忽略就是會跳過binlog中關於__osc_chg_orders臨時表的事務，但是binlog還會記錄，如果在主庫中忽略就是直接不記錄binlog，從庫自然就無法同步到，這裏採用從庫忽略binlog中這個__osc_chg_orders臨時表，修改配置文件:
忽略後發現可以跳過所有__osc_chg_orders臨時表相關的錯誤事務，但是還會出現錯誤代碼1032的事務，隨後按照這種思路進行查找，自己遇到的問題別人可能事先都已經遇到了，查找後發現有忽略錯誤代碼的配置：
忽略後出現1032的報錯，在修改忽略1032的報錯，問題解決，同步正常
參考跳過錯誤代碼：
最後只能手動修改從庫的表結構，主從同步恢復正常，至此問題解決，然後對照主庫的binlog事務在從庫中進行查詢，正常的insert binlog事務，在從庫中可以查詢到，說明binlog中的正常事務是被同步正常，只是跳過了錯誤事務，保證了主從之間的數據一致性
從庫修改簡單總結如下：
1、採用跳過單個事務的辦法，發現錯誤事務太多，中間又混雜着正確的事務，導致無法一次性跳過所有的錯誤事務
2、採用忽略特性錯誤事務的同步，發現所有有問題事物都是因爲同步一張臨時表而導致的，只需要跳過這個臨時表，這樣就能跳過大部分的錯誤事務，正常執行的事務也不會被影響，同樣會被同步
3、採用忽略同步錯誤代碼來實現，直接跳過同錯誤代碼的事務，恢復同步
4、比對主庫binlog中正常事務是否在從庫執行，查詢在主庫binlog中的正常insert事務，在從庫中進行select對應插入數據，可以查詢到，說明其中的正常事務通過binlog同步到從庫成功，至此解決了主從不同步的問題！
--------------------- osc bug解決 ----------------------------------------
這裏要注意一點就是binlog要使用ROW模式
1.解決了不支持ip+port的模式，官網只支持socket的方式，也就是只能在本地數據庫運行，但目前大多都是雲數據庫，所以只有socket連接方式不能滿足目前的需求，修改源碼後支持了host+port的方式
2.解決主從不一致的問題，官網只支持單庫的情況，也就是主從的情況只會修改主庫的表結構，並不會修改從庫的表結構，原因是在每次修改前OSC都會將數據庫的binlog關閉，導致生成的臨時表無法通過binlog同步到從庫，修改源碼讓其不關閉binlog，解決了主從不同步的問題
PS：官網這麼做可能考慮到寫binlog性能會下降，的確如此，但是對於目前雲庫的性能來說基本沒有影響，可以正常的修改表結構，測試1千萬的表修改表結構也就10分鐘左右，效率很高，而且不會影響線上業務的持續運行
官方GitHub OSC：https://github.com/facebookincubator/OnlineSchemaChange
改良後的git地址: https://github.com/lxshopping/OnlineSchemaChange