本文主要介紹了TiDB在小米的應用實踐和壓測資料，以及在小米場景下遇到的問題和解決辦法。上篇文章回顧:網路工程師眼中的自動化運維
1.TiDB應用實踐
1.1TiDB特點
TiDB 結合了傳統的 RDBMS 和 NoSQL 的最佳特性，相容 MySQL 協議，支援無限的水平擴充套件，具備強一致性和高可用性，具有如下的特性：
高度相容 MySQL，大多數情況下無需修改程式碼即可從 MySQL 輕鬆遷移至 TiDB，即使已經分庫分表的 MySQL 叢集亦可通過 TiDB 提供的遷移工具進行實時遷移。
水平彈性擴充套件，通過簡單地增加新節點即可實現 TiDB 的水平擴充套件，按需擴充套件吞吐或儲存，輕鬆應對高併發、海量資料場景。
分散式事務，TiDB 100% 支援標準的 ACID 事務。
真正金融級高可用，相比於傳統主從 (M-S) 複製方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 資料強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。
TiDB 的架構及原理官網有詳細介紹（pingcap.com/），這裡不再贅述。
TiDB基礎架構圖
1.2背景
關係型儲存資料庫首選 MySQL，單機 2.6T 磁碟。由於手機銷量的快速上升和 MIUI 負一屏使用者量的快速增加，導致負一屏快遞業務資料的資料量增長非常快，每天的讀寫量級均分別達到上億級別，資料快速增長導致單機出現瓶頸，比如效能明顯下降、可用儲存空間不斷降低、大表 DDL 無法執行等，不得不面臨資料庫擴充套件的問題。比如，我們有一個業務場景（智慧終端），需要定時從幾千萬級的智慧終端高頻的向資料庫寫入各種監控及採集資料，MySQL 基於 Binlog 的單執行緒複製模式，很容易造成從庫延遲，並且堆積越來越嚴重。
對於 MySQL 來講，最直接的方案就是採用分庫分表的水平擴充套件方式，綜合來看並不是最優的方案，比如對於業務來講，對業務程式碼的侵入性較大；對於 DBA 來講提升管理成本，後續需要不斷的拆分擴容，即使有中介軟體也有一定的侷限性。同樣是上面的智慧終端業務場景，從業務需求看，需要從多個業務維度進行查詢，並且業務維度可能隨時進行擴充套件，分表的方案基本不能滿足業務的需求。
瞭解到 TiDB 特點之後，DBA 與業務開發溝通確認當前 MySQL 的使用方式，並與 TiDB 的相容性做了詳細對比，經過業務壓測之後，根據壓測的結果，決定嘗試將資料儲存從 MySQL 遷移到 TiDB。經過幾個月的線上考驗，TiDB 的表現達到預期。
1.3相容性對比
TiDB 支援包括跨行事務、JOIN、子查詢在內的絕大多數 MySQL 的語法，可以直接使用 MySQL 客戶端連線；對於已用 MySQL 的業務來講，基本可以無縫切換到 TiDB。
二者簡單對比如下幾方面：
功能支援
（1）TiDB 尚不支援如下幾項：
1）增加、刪除主鍵
2）非 UTF8 字符集
3）檢視（即將支援）、儲存過程、觸發器、部分內建函式
4）Event
5）全文索引、空間索引
預設設定
（1）字符集、排序規則、sql_mode、lower_case_table_names 幾項預設值不同
事務
（1）TiDB 使用樂觀事務模型，提交後注意檢查返回值。
（2）TiDB 限制單個事務大小，保持事務儘可能的小。
TiDB 支援絕大多數的 Online DDL
另，一些 MySQL 語法在 TiDB 中可以解析通過，不會產生任何作用，例如： create table 語句中 engine、partition 選項都是在解析後忽略。
詳細資訊請訪問官網：pingcap.com/docs-cn/sql…
2.壓測
2.1目的
通過壓測 TiDB 瞭解一下其 OLTP 效能，看是否滿足業務要求。
2.2機器配置
2.3壓測內容及結果
1.標準Select壓測
2.標準OLTP壓測
3.標準Insert壓測
2.4壓測總結
通過壓測發現 TiDB 穩定性上與預期稍有差別，不過壓測的 Load 會明顯高於生產中的業務 Load，參考低 Threads 時 TiDB 的表現，基本可以滿足業務對 DB 的效能要求，決定灰度一部分 MySQL 從庫讀流量體驗一下實際效果。
2.5遷移過程
整個遷移分為 2 大塊：資料遷移、流量遷移
2.6資料遷移
資料遷移分為增量資料、存量資料兩部分。
對於存量資料，可以使用邏輯備份、匯入的方式，除了傳統的邏輯匯入外，官方還提供一款物理匯入的工具 TiDB Lightning。
對於增量備份可以使用 TiDB 提供的 Syncer （新版已經更名為 DM - Data Migration）來保證資料同步。
(1)Syncer 簡介
主要依靠各種 Rule 來實現不同的過濾、合併效果，一個同步源對應一個 Syncer 程式，同步 Sharding 資料時則要多個 Syncer 程式。
Syncer結構圖
使用 Syncer 注意事項
（1）做好同步前檢查，包含 server-id、log_bin、binlog_format 是否為 ROW、binlog_row_image 是否為 FULL、同步相關使用者許可權、Binlog 資訊等。
（2）使用嚴格資料檢查模式，資料不合法則會停止。資料遷移之前最好針對資料、表結構做檢查。
（3）做好監控，TiDB 提供現成的監控方案。
（4）對於已經分片的表同步到同一個 TiDB 叢集，要做好預先檢查。確認同步場景是否可以用 route-rules 表達，檢查分表的唯一鍵、主鍵在資料合併後是否衝突等。
2.7流量遷移
流量切換到 TiDB 分為兩部分：讀、寫流量遷移。每次切換保證灰度過程，觀察週期為 1~2 周，做好回滾措施。
讀流量切換到 TiDB，這個過程中回滾比較簡單，灰度無問題，則全量切換。
將寫入切換到 TiDB，需要考慮好資料回滾方案或者採用雙寫的方式（需要斷掉 Syncer）。
3.叢集狀態
3.1配置
叢集配置採用官方推薦的 7 節點配置，3 個 TiDB 節點，3 個 PD 節點，4 個 TiKV 節點，其中每個 TiDB 與 PD 為一組，共用一臺物理機。後續隨著業務增長或者新業務接入，再按需新增 TiKV 節點。
3.2監控
監控採用了 TiDB 的提供的監控方案，並且也接入了公司開源的 Falcon，目前整個叢集執行比較穩定，監控如下圖。
3.3問題及解決方式
| 問題 | 原因及解決方式 |
| 在一個 DDL 裡不能對多個列或者多個索引做操作。 | ADD/DROP INDEX/COLUMN 操作目前不支援同時建立或刪除多個索引或列，需要拆分單獨執行，官方表示 3.0 版本有計劃改進。 |
| 部分操作符查詢優化器支援不夠好，比如 or 操作符會使用 TableScan，改寫成 union all 可避免 | 官方表示目前使用 or 操作符確實在執行計劃上有可能不準確，已經在改進計劃中，後續 3.0 版本會有優化。 |
| 重啟一個 PD 節點的時候，業務能捕捉到 PD 不可用的異常，會報 PD server timeout | 因為重啟的是 Leader 節點，所以重啟之前需要手動切換 Leader，然後進行重啟。官方建議這裡可以通過重啟前做 Leader 遷移來減緩，另外後續 TiDB 也會對網路通訊相關引數進行梳理和優化。 |
| 建表語句執行速度相比 MySQL 較慢 | 多臺 TiDB 的時候，Owner 和接收 create table 語句的 TiDB Server 不在一臺 Server 上時，可能比 MySQL 慢一些，每次操作耗時在 0.5s 左右，官方表示會在後續的版本中不斷完善。 |
| pd-ctl 命令列引數解析嚴格，多一個空格會提示語法錯誤 | 官方表示低版本中可能會有這個問題，在 2.0.8 及以上版本已經改進。 |
| tikv-ctl 命令手動 compact region 失敗 | 在低版本中通常是因為 tikv-ctl 與叢集版本不一致導致的，需要更換版本一致的 tikv-ctl，官方表示在 2.1 中已經修復。 |
| 大表建索引時對業務有影響 | 官方建議在業務低峰期操作，在 2.1 版本中已經增加了操作優先順序以及併發讀的控制，情況有改善。 |
| 儲存空間放大問題 | 該問題屬於 RocksDB，RocksDB 的空間放大係數最理想的值為 1.111，官方建議在某些場景下通過 TiKV 開啟 RocksDB 的 dynamic-level-bytes 以減少空間放大。 |
4.後續
目前 TiDB 主要提供 OLTP 服務，負一屏快遞業務為使用 TiDB 做了一個良好的開端，而後商業廣告也有接入，2 個業務均已上線數月，TiDB 的穩定性經受住了考驗，帶來了很棒的體驗，對於後續大體的規劃如下
MIUI 生態業務中存在大量的類似場景的業務，後續將會與業務開發積極溝通，從 MySQL 遷移到 TiDB。
針對某些業務場景，以資源合理利用為目標，推出歸檔叢集，利用 Syncer 實現資料歸檔的功能。
資料分析，結合 TiDB 提供的工具，將支援離線、實時資料分析支援。
將 TiDB 的監控融合到Open Falcon 中。
本文首發於公眾號”小米運維“，點選檢視原文。