1. 概要

每臺機器都使用多例項的模型。 每個機器放多個例項，每個例項放多個DB。

一些資訊可以參考： https://www.youtube.com/watch?v=UBHcmP2TSvk

多例項之間沒有進行資源隔離，這麼做是讓每個例項都能發揮最大效能。

目前大部分核心業務已切換成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最常遇到的主從資料延遲問題。

6. 團隊結構及技能樹

DBA團隊更多的是負責私有DB雲平臺的建設。

Schema設計及DB拆分等由效能優化團隊負責。

線上表結構變更：資料庫資源申請由質量服務團隊負責，做到資源的合理分佈、分配，如果某個業務只需要個位數級別的DB例項，可以自行在私有DB雲平臺中申請部署，當數量比較大時，需要先經過質量服務團隊評估通過。

資料庫資源申請由質量服務團隊負責，做到資源的合理分佈、分配。如果某個業務需要小量DB例項，可以自行在私有DB雲平臺中申請部署；當數量比較大時，需要先經過質量服務團隊評估通過才可以。

文章來自微信公眾號：雲DB