作者：賀磊
我先說幾個最讓你興奮和開心的點吧：
在 TiDB 里，你完全不用擔心磁盤容量的問題。
在 TiDB 里，原生支持 Online DDL，你完全不用擔心第三方改表工具改表出現各種 Bug 的問題，相信用開源工具改過上 T 級別表的同學都遇到過或多或少的各類 error。
在 TiDB 里，加列，主鍵擴容字段都是秒級的，比如我剛剛就剛對一張 19 億的表加完了字段，1 秒完事，這在 MySQL 里要 8.0 才可以，而且還要求列在最后才行。
在 TiDB 里，你會發現 count() 驚人的快，一張近 20 億的表 coun() 大概在 1 分鐘完事兒，當然，這取決于你的 KV 數量和磁盤性能。
在 TiDB 里，從 MySQL 遷移將變得簡單，圖形化一鍵遷移，爽不爽？
在 TiDB 里，絕大多數情況你會發現比單機 MySQL 有更好的性能，當然也不排除一些例外，例如 enum 這樣奇葩的字段類型。
在 TiDB 里，......，您且往下看，我慢慢和您說。
使用背景
360 云平臺對 360 集團各大業務線均有提供服務支持，涉及的數據庫支持方案有：MySQL、Redis、MongoDB、ES、GP、PiKA。其中 MySQL 至今已有過萬的實例，目前，對于一些寫入量大的業務，已經出現瓶頸。例如磁盤空間，雖然我們可以通過分庫分表的方式，拆分出來，但這對業務和 DBA 來說都是不小的工作量，最痛苦的無異于這些大表的改表。無論是單表上 T，還是分庫分表，對一張大表執行 DDL 的代價是非常大的。針對業務爆發式增長的數據量，我們開始調研選型是否有其他數據庫可以代替傳統的 MySQL。通過調研我們了解到 TiDB，遷移平滑，基本上無需業務變動代碼，完全的事務 ACID 支持，分布式的架構，自帶高可用、Online DDL。截止目前，360 云平臺這邊有三套 TiDB 集群，總節點數在 50+。有 9 個業務線接入使用，有過百億級表 Online 加索引的案例，總數據量目前在 80T。版本上，我們從 3.0.1 一路跟隨到 3.0.5，DM 版本從內測到 1.0.2 GA 版本，共計提出 9 個 Bug 或改進項反饋。后續我們計劃將 TiDB 上到 360 HULK 云平臺上，并定制化開發一些功能為業務提供可視化的服務，以便讓 360 集團更多的業務線接觸到 TiDB、使用 TiDB。版本的選擇我們之所以從大版本 3 開始，也是看到了一些 2.X 版本的社區反饋，尤其是索引執行計劃這塊，3.X 版本較之前的版本會好很多。DM 版本我們是直接選取的最新版，后一路跟隨新版本升級。
集群架構
整體架構上，我們除了 TiDB 集群外，還用到了 DM 和 Pump、Drainer 套件。這塊主要是由于我們使用 TiDB 的業務有兩種：①老的 MySQL 業務，因單機磁盤受限，導致單實例磁盤無法支撐爆炸式增長的數據量，數據比較重要，需要備份和支持 7*24 小時的恢復。這類業務我們用到 DM 套件來實現無障礙遷移，1TB 的導入時間在 16 小時，這里如果是比較大的數據源，且 TiDB 是全新集群，可以使用 TiDB-Lightning，速度可以更快。Lightning 的實測導入速度，37 分鐘，導完 2 張大表共計 54G 的數據，符合 100G/H 預估，是 loader 的 3 倍速度，loader 用時 2 小時 4 分鐘。
說起 DM 使用這塊文章后面會單獨分享下這塊需要注意的問題，如下圖所示：
②全新的業務，或由業務自行導入到 TiDB 集群中，這種業務數據量一般都會比較大，也是看中了 TiDB 支持 ACID 和分布式的特點。目前網盾業務有多張表都過 10 億級別，其中有張表到達了 100 億+，建索引花了近 10 天（這塊其實我們應當注意，不是分布式就一張表就完事兒了，因為表量級過大，清理老舊數據都是個問題）。TiDB 現在支持分區表，但我們在使用過程中發現性能上和普通表有差距，期待后續版本能夠讓分區表功能和性能更加的完善。
TiDB 在 360 云平臺的使用情況
對于這一全新的數據庫，我們本著大膽用，不拘泥于傳統的態度進行使用。我們的 MySQL 現在也正在適配 8.0 版本，MongoDB、ES 也都是時刻關注著新版本情況來評估是否適合云平臺。因此 TiDB 的上線也是從離線業務→邊緣業務→核心業務來過渡的。經過大量的測試、也參考了其他公司的使用情況，我們計劃將 TiDB 納入 360 HULK 云平臺，并計劃后期對其不斷完善在云平臺中的功能，對全公司業務線開放使用。定制化開發一些 MySQL 已經具備的，例如 SQL 審核、慢查統計、冗余索引檢測、自增索引閾值等各項基礎功能等等。雖然在使用過程中遇到了一些小問題，例如索引的選取、參數的調優，因為一些配置導致的性能抖動，但都得到了 PingCAP 同學快速的響應和回復，這對我們推進 TiDB 有重大的幫助。
一鍵遷移工具 DM 干貨分享
DM 使用經驗如下：
①權限
官網手冊上只說明需要如下權限：TiDB Lightning 需要以下權限：
SELECT
UPDATE
ALTER
CREATE
DROP
存儲斷點的數據庫額外需要以下權限：
INSERT
DELETE
但實測過程中發現還需要如下權限：
上游 （REPLICATION SLAVE 權限必須具備，要不增量同步會 access deny）。
下游 （不加 super 會導致 checksum table 無法執行）。
②TiKV Region Score
PD 監控中 -Statistics-balance 中，有 Store-region-score 監控項，這里記錄的是各個節點的 Score 得分，正常情況下，我們期望的結果是得分接近的，這說明無需進行 Region 大規模遷移。③PD 調度原理Region 負載均衡調度主要依賴 balance-leader 和 balance-region 兩個調度器。二者的調度目標是將 Region 均勻地分散在集群中的所有 Store 上，但它們各有側重：
balance-leader 關注 Region 的 Leader，目的是分散處理客戶端請求的壓力。
balance-region 關注 Region 的各個 Peer，目的是分散存儲的壓力，同時避免出現爆盤等狀況。
我們這里重點關注的是 balance-region，當它出現不均衡的時候，我們可以直接在監控中看到類似下圖所示：
調度期間，不可避免的會出現 IO 爭用、磁盤的 lantency，都會出現不同程度的上漲，從業務上的反饋看，就會出現積壓，響應不及時等等。而當 Region Balance 完成后， Duration 等都會恢復正常水平。因此，我們要關注的地方有兩點：
如何控制或減小 Region Balance 大規模遷移時對業務的影響；
如何提前規避因磁盤導致的大規模 Region Balance。
對于第一點，我們遷移的時候是有參數可以控制的。這里無論是磁盤空間閾值，還是 Region Balance 調度速度，或者 Drop 大量表后調整空 Region Merge 的速度，其實都是可以通過 pd-ctl 的 config set 命令來實時調節。例如：
high-space-ratio 0.7 #設置空間充裕閾值為 0.7。當節點的空間占用比例小于指定值時，PD 調度時會忽略剩余空間這個指標，主要針對實際數據量進行均衡。
region-schedule-limit 8 #最多同時進行 8 個 Region 調度。這個值主要影響 Region Balance 的速度，值越大調度得越快，設置為 0 則關閉調度。Region 調度的開銷較大，所以這個值不宜調得太大。也可以通過減小該值來限制調度region對集群產生的影響。
merge-schedule-limit 12 #最多同時進行 12 個 merge 調度。設置為 0 則關閉 Region Merge。Merge 調度的開銷較大，所以這個值不宜調得過大。
leader-schedule-limit 8 #最多同時進行 8 個 leader 調度。這個值主要影響 Leader Balance 的速度，值越大調度得越快，設置為 0 則關閉調度。Leader 調度的開銷較小，需要的時候可以適當調大。
max-merge-region-keys 50000 #設置 Region Merge 的 keyCount 上限為 50k。當 Region KeyCount 大于指定值時 PD 不會將其與相鄰的 Region 合并。
max-merge-region-size 16 #設置 Region Merge 的 size 上限為 16M。當 Region Size 大于指定值時 PD 不會將其與相鄰的 Region 合并。設置為 0 表示不開啟 Region Merge 功能。
TIPS：理解了作用和原理，上述參數都可以根據需求自行控制。
例如當我們在 Drop 大量的表后，會產生很多的空 Region。在 Region 數量較多的情況下，Raftstore 需要花費一些時間去處理大量 Region 的心跳，從而帶來一些延遲，導致某些讀寫請求得不到及時處理。
如果讀寫壓力較大，Raftstore 線程的 CPU 使用率容易達到瓶頸，導致延遲進一步增加，進而影響性能表現。
因此我們會希望盡快的進行 Region Merge，來避免過多的 Region 對集群造成性能損耗時，我們可以同時調小 max-merge-region-keys、max-merge-region-size，來讓其更快的觸發 Merge 操作，同時調大 merge-schedule-limit 提高并發度。
例如當我們發現某臺 KV 磁盤空間剩余 40% 開始大量調度時，我們可以將 high-space-ratio 調整到 0.7，以臨時避免調度對業務產生的影響。
我們也可以控制調度的并發度，來減少對業務產生的影響，實測這都是立竿見影的參數，大家如果遇到這些問題可供參考。
對于第二點，尤其是使用 DM 期間，將 DM-worker 和 TiKV 混合部署的情況下，要注意清理全量備份留下的文件和 Relaylog。
默認調度策略是當磁盤剩余的有效空間不足 40%，處于中間態時則同時考慮數據量和剩余空間兩個因素做加權和當作得分，當得分出現比較大的差異時，就會開始調度。所以 DM 導入完成后，要記得刪除全量備份。就是 dumped_data.task_xxx 文件夾，這個全量備份一般都會比較大，如果 dm-worker 和 TiKV 混部，就會出現某個 TiKV 節點磁盤已使用率高于其他。
這時 PD 的 store region score 就會相比其他節點出現異常，引起性能抖動和 Duration 升高。
一直等待其追上后，才會像下圖這樣：
此時，balancer 已達平衡狀態：
Duration 恢復正常水平，如下圖 16:54 分時的情況：
QPS 也不再積壓，恢復正常水準：
關于 relay-log，默認是不清理的，就和 MySQL 的 expire_logs_days 一樣，這塊可以通過 dm-worker 的配置文件來進行配置。
例如將 Expires 配置為 7，代表 7 天后刪除：
[purge]
interval = 3600
expires = 7
remain-space = 15
Expires 來控制保留天數。默認 expires=0，即沒有過期時間，而 remain-space=15 意思是當磁盤只剩于 15G 的時候開始嘗試清理，這種情況我們極少會碰到，因此這個清理方式其實基本上是用不到的。所以建議有需要刪除過期 relay-log 的小伙伴，直接配置 Expires 保留天數就可以了。DM 導入完成后，應該提供是否在完成后自動刪除全備文件的選項，可以默認不刪，由使用者決定是否刪除。從使用者角度來說，全量備份目錄無論是全量一次性導入還是 all 增量同步，后續都不會再使用到。如果 dm-worker 和 TiKV 混部，會導致全備文件占據大量磁盤空間，引起 TiKV Region 評分出現異常，導致性能下降，已轉化為 PRM 產品需求。
④關于 DM 使用期間出現數據丟失的問題
在早期還沒有 dm-portal 自動化生成 task 時，我們都是自行編寫 DM 的 task 同步文件。后來有了 dm-portal 自動化生成工具，只要圖形頁面點點點就可以了。
但該工具目前有一個問題是，沒有全庫正則匹配，即便你只勾選一個庫，他底層是默認把每張表都給你配置一遍。這就會出現當上層 MySQL 新創建某張表的時候，下游會被忽略掉，例如當你使用改表工具 gh-ost 或者 pt-online-schema-change，你的臨時表都會被當做為不在白名單內而被忽略，這個問題使用者需要注意。
我們也已經反饋給了官方。未來不久的版本估計就可以修復。
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD COLUMN `raw_url_md5` CHAR(32) NOT NULL DEFAULT '' COMMENT 'raw_url md5'"]
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD INDEX `idx_rawurl_md5`(`raw_url_md5`)"] [schema=flow]
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` DROP INDEX `idx_raw_url`"] [schema=flow]
這里日志可以看到 event 被 skip 了。
⑤關于 DM 使用期間偶發性 1062 主鍵沖突的問題
query-error task 能看到具體的報錯信息，下游看都沒有該值：
mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';
Empty set (0.00 sec)
再去上游看，結果發現也沒有值，業務邏輯應該是后來 delete 了：
mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';
Empty set (0.00 sec)
因為上游也沒有值，去上游看 Binlog 后分析如下：是先寫入，再刪除，所以上游沒值是可以預期的，但是下游還沒有同步到這塊，此時也是沒有值的，不應該存在 1062 的問題。當集群有大規模 kv:1062 報錯時，或者集群寫入壓力大時，DM 從結果看無法保證 Binlog 的有序落盤，需確認 DM能不能保證 LVS 下的多個 TiDB Binlog 的每一個 Event 是有序執行的。只從現象看，只要集群沒有大量的 1062 報錯，PD 相關的監控值都比較低，DM 也不會出現任何同步報錯，反之就出現。從 Binlog 看就像是第一條 Insert了，還沒來得及 Delete，直接 Insert 產生的報錯，但報錯后那個 Delete 的也完成了，所以這時候我再怎么快也快不到毫秒級，下游看不到所有記錄。解決的辦法是將 1062 大量沖突的業務拆分出集群，或 DM 直接寫 TiDB 的真實 IP 而不是 LVS。⑥DM 同步異常有業務反饋 Drop 分區和 Drop 列時出現同步異常。補充下分區表相關的測試的結果，DM 更多的無法拆分的情況還是在 Drop 這塊，普通的 add，modify 沒問題的。一次刪除多個分區的操作則會報錯：
alter table dsp_group_media_report drop partition p202006 ,p202007 ;
Drop 含有索引的列操作會報錯：
Alter table dsp_group drop column test_column;
40 億表添加 DDL 添加索引導致的 Duration 升高：
定位到是：
mysql> show global variables like 'tidb_ddl_reorg_worker_cnt';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| tidb_ddl_reorg_worker_cnt | 16 |
+---------------------------+-------+
1 row in set (0.11 sec)
mysql> show global variables like 'tidb_ddl_reorg_batch_size';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| tidb_ddl_reorg_batch_size | 1024 |
+---------------------------+-------+
上述兩個參數對已有非 pcie 集群壓力比較大導致。通過 set global 調節（3.0.3 后，默認從 256 漲到了 1000 和 16）：
tidb_ddl_reorg_batch_size 1000-256
tidb_ddl_reorg_worker_cnt 16-4
同時，提高 Compaction 相關：
max-background-jobs: 8-10-12
max-sub-compactions: 1-2-4
defaultcf.compression-per-level: ["lz4", "lz4", "lz4", "lz4", "lz4", "zstd", "zstd"]
writecf.compression-per-level: ["lz4", "lz4", "lz4", "lz4", "lz4", "zstd", "zstd"]
最終的優化結果是，QPS 穩定在 3K 左右：
⑦靜默 Region 開啟在實際情況中，讀寫請求并不會均勻分布到每個 Region 上，而是集中在少數的 Region 上。那么可以盡量減少暫時空閑的 Region 的消息數量，這也就是 Hibernate Region 的功能。無必要時可不進行 raft-base-tick，即不驅動空閑 Region 的 Raft 狀態機，那么就不會觸發這些 Region 的 Raft 產生心跳信息，極大地減小了 Raftstore 的工作負擔。截至 TiDB v3.0.5，Hibernate Region 仍是一個實驗功能，在 TiKV master 分支上已經默認開啟。可根據實際情況和需求來開啟該功能。
參數如下：
raftstore.hibernate-regions: true
⑧DM 導入期間 Duration 升高
在 DM 導入集群期間，確實會因為寫熱點的問題導致集群整體 Duration 更高，因為 IO 爭用會更明顯。這里其實也是可以通過一些參數來讓集群運行的更快的。
如下參數從原值調到-新值：
raftstore:
apply-pool-size: 3-4
store-pool-size: 3-4
storage:
scheduler-worker-pool-size: 4-6
server:
grpc-concurrency: 4-6
rocksdb:
max-background-jobs: 8-10
max-sub-compactions: 1-2
可以看到效果如下：QPS 不再抖動，Duration 也恢復到正常的水平。
⑨DM Debug 相關DM 還有個注意點就是 dm-worker.toml 配置文件里的配置 log-level=“debug” 是不生效的，啟動的時候默認有個 -L=info 選項，會覆蓋掉配置文件里的，默認 -L 優先級高于配置文件，人工排查時自行啟動。也就是說當需要對 dm-worker 開啟 debug 模式，要人工拉起進程并指定 -L 選項=debug。⑩TiDB load data 速度不理想TiDB 目前 load data 的導入速度不及 MySQL，如果依賴 load data 的話，這塊可以調優一下參數。
我們的場景是 TiKV 上沒有明顯的瓶頸，主要慢在了 scheduler latch wait duration，可以調下參數看看：
storage:
scheduler-concurrency: 204800000
raftstore:
raft-max-inflight-msgs: 4096
調優完成后是有提升，但提升不大，我們得知新版本的 TiDB 在 Load data 這塊又有速度提升，比較期待新版本。
其他干貨打包分享
①TiDB 列數超限MySQL 是 1024，TiDB 目前限制是 512 列。如果你的表有非常多的列，那么這塊要提前注意下是不是可以拆分出去。②GC can not workGC 的數據包括兩部分，一部分是 DML 和 DDL ，DDL 的 GC 的對象信息包含在 mysql.gc_delete_range 和 mysql.gc_delete_range_done ，分別記錄的是待 GC 的對象以及已經 GC 的對象。mysql.gc_delete_range_done表里面沒有數據不代表 GC 異常。
官方建議更換規則：
sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d]))
③TiDB or 條件優化
在 TiDB 中，如下查詢是不能用到索引的：
select * from manual_domain where host_md5 = '55fbea39965484a61xxxxxxxxxx' or domain_md5 = '55fbea39965484a61xxxxxxxxxx';
MySQL 中用到了 index_merge，TiDB 計劃 4.0 支持，可以先用 union all 來處理這種 a or b。④Coprocessor CPU 消耗過大
業務反饋查詢變慢，發現是另外一個業務全表掃 insert into select 導數據導致的。
去 CPU 占用率高的這臺機器上搜索對應的 log，關鍵字 slow，發現如下情況：
[2019/09/18 10:04:37.339 +08:00] [INFO] [tracker.rs:150] [slow-query] [internal_key_skipped_count=46649] [internal_delete_skipped_count=0] [block_cache_hit_count=1596] [block_read_count=9] [block_read_byte=31933] [scan_first_range="Some(start: 7480000000000002285F72800000000021E9BD end: 7480000000000002285F72800000000024199A)"] [scan_ranges=1] [scan_iter_processed=46650] [scan_iter_ops=46652] [scan_is_desc=false] [tag=select] [table_id=552] [txn_start_ts=411244239493267464] [wait_time=2ms] [total_process_time=1.41s] [peer_id=ipv4:192.168.1.248:45686] [region_id=835437]
根據 table_id 去通過 information_schema.tables 表查一下，可以通過上述方式來定位到是哪張表導致的問題。TiDB enum 導致的性能問題：
enum 在 TiDB 3.0.2 進行 where 條件查找時，發現不能下推到 TiKV。官方說4.0GA 修復。臨時辦法是修改到其他類型。
enum modify 為 tinyint 發現內容出現變化，原本的’'變成了 default 值，‘1’ 變成了 2，經測試 varchar 正常，因此不要嘗試去變更 DM 備份出來的 Schema 文件來實現表結構變更，應該從上游 MySQL 解決。
⑤分區表元數據無法獲取沒有視圖可以查詢當前已建分區信息。在 TiDB 中目前沒有視圖支持查詢分區表已建分區信息，那么用戶那邊沒有辦法直觀的判斷當前已建的分區，以及當前是否需要及時的添加新分區。目前已轉化為 PRM 產品需求，相信新版本不久會實現。分區表 - 部分分區 - limit 未下推：分區表出現 limit 未下推的現象，表 content_info_p 其中只有分區 p201911 有數據。該問題已在 3.0.6 版本修復。mysql.tidb 表權限異常：使用 use db_name 或者 mysql 客戶端指定 DB name 后，可以對該表進行查詢或更新操作。計劃 3.1 版本修復。事物的限制：單個事物的 SQL statement 不超過 5000（stmt-count-limit 參數可調）；每個鍵值對不超過 6M；鍵值對的總數不超過 300000；鍵值對的總大小不超過 100M。注：鍵值對是指一張表里有 2 個索引，那么一共就是數值 +2 個索引，總共 3 個鍵值對，那么每個鍵值對的總是不能超過 30 萬/3=10 萬。一行數據會映射為一個 KV entry，每多一個索引，也會增加一個 KV entry，所以這個限制反映在 SQL 層面是：總的行數*(1+索引個數)<30w。官方提供內部 batch 的方法，來繞過大事務的限制，分別由三個參數來控制：
tidb_batch_insert
tidb_batch_delete
tidb_dml_batch_size
寫熱點的處理：如果可以去掉 MySQL 自增主鍵，就可以通過建表時指定 SHARD_ROW_ID_BITS、PRE_SPLIT_REGION 來實現預切分，避免單調自增引發的只往某個 KV 上寫數據引起的熱點問題。詳情可參考官網 TiDB 專用系統變量和語法中 SHARD_ROW_ID_BITS 的介紹。⑥TiDB 監控和 DM 監控 Ansible 部署數據沖突這塊可以通過將 TiDB 和 DM 監控部署到不同的機器上來繞過解決，否則就會出現通過 Ansible 安裝后，ansible-playbook rolling_update_monitor.yml --tags=prometheus 時，兩者只有一個是正常的。磁盤已使用不建議超過 50%：數據量太多 LSM 過大， compaction 成本會很高，并且內存命中率下降，同時單機恢復時間很長，50% 左右最好，使用率太高，如果突然寫入爆增，region 來不及調度會寫滿磁盤，有風險。因此建議 SSD 不要使用超過 2T 的，采用更多的機器會有更好的性能。⑦Mydumper 導致的內存和網卡打滿
在使用 Mydumper 備份大時，會打滿 TiDB 網卡，同時會消耗 TiDB、TiKV 更多的內存。
【TiDB ERR】[emergency]TiDB_schema_error:192.168.1.1:10080,[add_dba_mysql]【360】
【TiDB ERR】[critical]NODE_memory_used_more_than_80%:192.168.1.2:9100,[add_dba_mysql]【360】
去抓取慢日志會看到如下內容：
grep Query_time tidb_slow_query-2019-12-24T04-53-14.111.log|awk -F : '$2>10'
# Time: 2019-12-24T03:18:49.685904971+08:00
# Txn_start_ts: 413433784152621060
# User: backup@192.168.1.3
# Conn_ID: 4803611
# Query_time: 4002.295099802
SELECT /*!40001 SQL_NO_CACHE */ * FROM `360`.`t_d` ;
期待后續的版本物理備份，邏輯備份看起來目前是可以備份，但會比較消耗資源，同時恢復時間也會更久。
展望
從 TiDB 2.x 開始我們就已經開始進行測試了，最終選擇的版本是 3.0.2，后續升級到 3.0.5。上述文章總結和一些案例希望能夠幫助到已使用或打算使用 TiDB 的朋友。360 云平臺 DBA 團隊也計劃將 TiDB 推上 360 HULK 云平臺，為 360 集團更多的業務線提供豐富多彩和穩定可靠的數據庫服務。在這里首先要感謝 PingCAP 同學及時的技術支持，幫助我們盡快的解決了一些技術問題。同時，我自己也通讀了 TiDB 的官方手冊。從 Ansible 部署、二進制部署、升級、DM、Lighting、Pump、Drainer、調優、排障、遷移、備份，這一路打怪下來，切身感受到了 TiDB 越來越好的過程。我相信未來隨著 3.1 和 4.0 版本的推出，有更多人加入使用 TiDB 的這個隊伍中來。從業務給我們的反饋也是對 TiDB 的使用情況表示滿意，我們相信，TiDB 會在大家共同的努力下，越來越好。作者：賀磊
簡介：360 數據庫運維資深工程師，《MongoDB 運維實戰作者》，知名論壇 MySQL 版主，51CTO 博客之星，閑暇之余，喜歡將部分案例寫成博客，累計訪問量過百萬。
原文：
