Facebook工程師親臨！關於MyRocks生產部署實踐！

各大資料庫排行榜上， MySQL都處於一個非常不錯的位置， 近幾年更是廣泛應用於各種業務場景中。 在Facebook， MySQL主要應用於存儲社交圖片、大規模碎片處理、純Flash存儲等。 RocksDB是facebook基於LevelDB實現的， RocksDB為MySQL的一個存儲引擎移植到MySQL， 稱之為MyRocks。 近幾年， MyRocks有了不錯的發展， 在本屆DTCC大會第二天的主會場， Facebook工程師Yoshinori Matsunobu講述了Facebook的MySQL資料庫從InnoDB遷移到MyRocks的故事！

Yoshinori Matsunobu

MyRocks的特點——Facebook為什麼選擇遷移呢？

Yoshi表示， 從集群索引來看， MyRocks與InnoDB相同， 並沒有明顯的優勢。 但其具有更快的資料載入、刪除和複製速度， 動態選項、TTL、使用XA的碰撞安全、線上邏輯和二進位備份、bloom filter、更多併發寫（計畫中）、直接IO以及優雅的sst檔刪除等特點。

雖然其具有非常不錯的性能， 但要想從InnoDB遷移到MyRocks還面臨著十分嚴峻的技術挑戰。

MyRocks遷移——技術挑戰與解決方案

在整個遷移過程中， Yoshi表示Facebook面臨著定義MyRocks優化架構、找出最佳Column Family選項、在不停機的情況下創建MyRocks實例、在合理的時間載入MyRocks表格、驗證InnoDB和MyRocks之間的資料一致性等問題，

同時， 為了保證系統的具體業務不受影響， 還需要對其進行連續監測， 即時瞭解計算資源的使用情況， 比如空間、iops、cpu和記憶體等， 查詢異常值， 並具備一定的系統恢復能力。

當在主機上運行MyRocks時， 還需要考慮RBR、移除InnoDB Gap Lock上的查詢依賴， 同時保證具備完美的XA支持（binlog和RocksDB）。 既然面臨各種技術挑戰， 自然是要尋找對應的解決方案。

Yoshi也在分享中給出了一些問題的相應解決方案， 比如如何在不影響服務的情況下創建一個MyRocks實例， 可以選擇一個InnoDB從站示例， 啟動邏輯轉儲和恢復（停止一個從站不會影響服務）， Facebook的MySQL複製環境是單主多從的方式， 從站分佈較遠， Facebook的實例中包含多個資料庫（多執行緒從庫有助於減少滯後）。

整體的遷移步驟大致如下：

目前國際上公開在生產環境使用MyRocks存儲引擎的只有Facebook和阿裡巴巴， Yoshi表示， 目前的MyRocks/RocksDB還是一個比較新的資料庫技術， 與強大的InnoDB相比可能會有更多bugs， 因此確保資料一致性有助於避免一些可能會出現的衝突。 在這之中， 有效測試就顯得至關重要。

Facebook也有一套相對完整嚴謹的測試體系， 其擁有一個shadow測試框架， 可從生產實例捕獲讀或寫查詢， 將它們重新映射到shadow主實例中。

針對測試、故障處理或生產環境部署中可能存在的問題， Facebook也將在開源社區進行一些具體的方案解答和技術交流。 回顧整個遷移過程， Yoshi表示， 當初的主要動機是為了節省空間， 遷移中建議使用線上資料正確性檢查工具， 有助於發現大量資料完整性錯誤， 並阻止在生產中部署不一致的實例， 採用批量裝載和快速索引的方式可有效優化壓縮過程， 同時一定要具備完善的錯誤恢復機制。

Yoshi也表示， 在平時的工作中會時刻關注中國相關領域的技術趨勢和變化， 也曾與國內一些互聯網公司有過一些技術交流，

未來， 他也希望可以與中國的技術人士有更深入的交流。