本文會簡要介紹，OnlineSchemaChange在經歷從PHP到Python重寫後的改進和變化

前言

Facebook早在2009年就開源了OnlineSchemaChange.php. 該工具主要設計初衷是用於補充當時MySQL對於線上表結構變更支援的空白，儘可能的減少表結構變更時對業務的影響。而在過去的幾個月中這個工具經歷了從PHP到Python重寫，以及功能的新增和效能的改進。今天，重寫後的OnlineSchemaChange正式宣佈開源，可通過此連結訪問：https://github.com/facebookincubator/OnlineSchemaChange

設計初衷和困境

最早，OSC是為了解決MySQL在進行表結構變更時鎖表所帶來的業務影響。同時，它也滿足一部分DDL無法提供的功能。例如：ALTER TABLE IGNORE ... ENGINE=INNODB。 然而在PHP的使用過程中我們發現設計上缺陷和程式編寫方式的問題導致這個工具的可擴充套件性較差，並且無法更好的進行功能測試。隨著時間的積累，往這個工具增加新功能的難度越來越高，甚至修復bug都成了一個不可能完成的任務。同時功能測試的缺失也成為了吸納社群貢獻的一個重大阻礙，致使整個專案的活躍度下降。 因此在去年我們決定重寫這個工具，同時加入更多我們嚮往已久的功能。

變化和改進

使用便捷

之前開源的OSC更多的像是一個概念和一段程式碼，本身無法直接使用。使用者需要自己把核心邏輯封裝成一個可執行的指令碼。這個大大增加的OSC的可用度也從而導致了社群的接納度不高。新版本的OSC.py是一個命令列可執行的指令碼，很大程度上提高了易用性成為一個下載即可使用的工具。 同時，OSC.py的核心邏輯也獨立成為Python Module存在。如果你的運維整體架構是基於Python搭建的那麼新的OSC.py將可以很容易的融合到你的工具集當中。

可測試性

受到mysql-test-run的啟發，新的OSC實現了一個類似的測試案例設計。及時是一個不懂Python的使用者也可以非常容易的寫出一個基於JSON+SQL的測試案例，提交一個issue來描述自己遇到的bug。同時這也使得吸納社群patch的可靠性大幅提高。 同時受益於Python語言本身，整個工具也實現很高的單元測試覆蓋度，可靠性有了很好的保障。

可靠性

和目前所有開源的線上表結構變更工具不同，OSC.py實現了一致性檢驗的功能。在Facebook資料一致性高於一切。一致性的檢驗可以讓我們非常放心在任何時刻進行任何表結構變更而不用擔心因工具bug而造成的資料丟失或者損毀。同時，一致性校驗也是一種對社群使用者負責的態度。MySQL的執行環境和配置引數千變萬化，而Facebook的線上環境所能涵蓋的只是一小部分。能在FB正常執行並不意味著這個工具就可以對bug免疫。一致性校驗的存在可以讓OSC.py優雅的避免各種環境變化所可能帶來的潛在bug對資料的損壞。

要詳細瞭解更多OSC.py帶來的新特性可以檢視這個wiki page

專案的展望

隨著Row Based Replication的普及和在Facebook內部的全面部署，我們將會增加基於RBR binlog增量記錄的功能，從而完全避免trigger模式帶來的效能損耗。同時，我們也將會將原生線上表結構變更的支援增加到智慧模式中，在實現一個工具滿足所有表結構變更的需求的同時達到最小的不可用時間。

最後我們也非常希望和開源社群一起對OSC進行改進和開發，使之能成為一個更為可靠高效的DBA工具。