1. 概要
每台機器都使用多執行個體的模型。 每個機器放多個執行個體，每個執行個體放多個DB。
多執行個體之間沒有進行資源隔離，這麼做是讓每個執行個體都能發揮最大性能。
目前大部分核心業務已切換成MyRocks引擎，在機器硬體配置不變的情況，約可節省一半機器。
放在MyRocks上的核心業務主要有：Feed、Post、社交圖譜等讀寫混合業務。
MyRocks項目位址：https://github.com/facebook/mysql-5.6
另外，MariaDB 10.2版本也即将整合MyRocks引擎。
2. 高可用機制
采用基于GTID的一主多從結構，外加一個基于lossless semi-sync機制的mysqlbinlog實作的binlog server(可以了解為MySQL 5.7的loss zero replication)。
基于多數派實作自動選主。
基于配置中心實作切換，未使用VIP。
在認為semi-sync複制可保證主從資料一緻性的假設前提下，發生故障切換時，利用上述的binlog server中的日志進行補全後再選新主、切換。
若個别情況下由于特殊原因，出現從庫全部挂掉的情況，會将全部請求切到主庫，由它扛起所有的業務服務壓力。
某個從庫挂掉時，可以動态摘除。
3. 備份機制
所有的備份都是基于mysqldump實作，之是以采用mysqldump邏輯備份好處有：
無需備份索引，隻備份資料；
備份檔案壓縮比高，更節省磁盤空間；
改進了mysqldump，備份過程中還進行額外壓縮；
上面提到，因為采用多執行個體、多DB結構，備份時可以多DB并行備份。當然了，也會控制并行備份的數量，避免影響線上業務性能。
備份放在集中存儲(HDFS)上， 據說已達EB級别容量。
關于備份的作用定位：
供資料分析環境拉資料
供災難恢複
4. 如何快速部署從庫
可使用xtrabackup在現有存活的SLAVE執行個體上備份，也可在主庫上發起備份，再利用WDT(或者是BT)協定傳輸到異地，用于拉起從庫。
關于WDT項目：https://github.com/facebook/wdt
5. 高度自動化
面對大規模的資料庫執行個體，手工處理完全不現實。目前在facebook主要是利用Python開發内部DB運維平台，是以Python技能方面要求比較高。
采用他們自已的osc工具執行Online DDL(也是本次DTCC大會上lulu的分享主題)，它最早用PHP開發，雖早已開源，但實在不好用，是以幾乎隻在内部使用。這個工具不同于pt-osc，相對來說更有優勢，比如可以避免使用pt-osc最常遇到的主從資料延遲問題。
項目位址：https://github.com/facebookincubator/OnlineSchemaChange
6. 團隊結構及技能樹
DBA團隊更多的是負責私有DB雲平台的建設。
Schema設計及DB拆分等由性能優化團隊負責。
線上表結構變更：資料庫資源申請由品質服務團隊負責，做到資源的合理分布、配置設定，如果某個業務隻需要個位數級别的DB執行個體，可以自行在私有DB雲平台中申請部署，當數量比較大時，需要先經過品質服務團隊評估通過。
資料庫資源申請由品質服務團隊負責，做到資源的合理分布、配置設定。如果某個業務需要小量DB執行個體，可以自行在私有DB雲平台中申請部署；當數量比較大時，需要先經過品質服務團隊評估通過才可以。