MySQL運維經驗

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雲平臺中申請部署；當數量比較大時，須要先通過質量服務團隊評估經過才能夠。

本文地址：https://www.linuxprobe.com/mysql-manage.html