㈠ tidb資料庫如何更改多列欄位
1、首先打開ManagementStudio軟體，輸賀迅入伺服器地址，接著輸入用戶名密碼點擊連接按鈕。
2、其次選中需要修改的欄位所冊拆在的資料庫，滑鼠右擊選擇新建查詢窗口。
3、然後在查詢窗口中先使用Select語句，查州拍棗詢表中欄位值。
㈡ TiDB修改配置參數
在TiDB 中，「修改配置參數」似乎是個不精準的說法，它實際包含了以下內容：
TiDB的配置修改比較混亂，先做個總結，再介紹具體內容：
查看TiDB系統變數：
集群中所有 TiDB Server 都生效；
持久化在哪裡？
持久化在 kv 存儲中，跟數據一樣持久化了，不會持久化在 conf/tidb.toml 配置文件中。所以不用擔心 tiup upgrade 和 tiup reload 等運維操作會把配置文件覆蓋，不會導致修改失效，因為這個修改的持久化不依賴配置文件。
有些參數的作用域只有會話級別。也就是只能會話級修改，這不代表著不能被動態修改。
修改方式和會話級修改一樣：
修改 Instance 級別的參數修改不會持久化，那麼如何持久化呢？
a. 手工修改 TiDB 的配置文件：
b. 並使用 tiup edit-config 來修改對應的配置項，不需要做 tiup reload：
內容如下：
目前查看官方文檔，發現只有3個只讀變數：hostname、tidb_config、tidb_current_ts，沒法通過 set variables 修改。作用域比較奇怪，用法介紹也不清楚，看起來沒有修改的必要。如果一定要修改可以通過 tiup 方法修改。
修改集群配置包括TiDB、TiKV 以及 PD 在內的各組件的配置進行修改。
使用 edit-config 命令來編輯參數，以編輯模式打開該集群的配置文件：
如果配置的生效范圍為該組件全局，則配置到 server_configs，比如修改所有 tikv 的 log-level 為 waring（默認是 info）：
如果配置的生效范圍為某個節點，則配置到具體節點的 config 中。例如：
tiup reload 分發配置並滾動重啟組件，無論是否可以動態修改的參數都會重啟，並且默認會重啟所有組件，可以選擇指定節點或者組件：
tiup cluster reload ${cluster-name} [-N <羨歷nodes>] [-R <roles>]
示例中我們只修改 tikv 的 log-level 為 waring，所以用 -R tikv 指定只重啟 tikv 節點：
set config 當前4.0版本屬於兄纖搜實驗性功能，不建議在生產使用： https://docs.pingcap.com/zh/tidb/stable/dynamic-config
目前只支持修改 TiKV 和 PD 的配置，TIDB的配置修改用上面的 set variables 方法。
查看當前參數設置：
用豎槐 set config 修改參數，會持久化到配置文件。log-level 無法動態修改，不會報錯但是會有 warnings，對於不能動態修改的參數使用 tiup 進行修改：
動態修改示例：
雖然TiKV的配置文件 conf/tikv.toml 會持久化這個修改，但是為了防止tiup upgrade 和 tiup reload 等運維操作把配置文件覆蓋導致修改失效，還需要執行 tiup edit-config 來編輯參數。
㈢ TiDB 基礎操作集
1、測試環境推薦配置
2、生產環境推薦配置
3、 如果 tikv 伺服器的 CPU及磁碟配置較高，可以考慮多實例部署，按照每個 tikv 實例16~20core + 64G 內存 + 800G 磁碟的比例分配硬體資派蠢源。
同時需要注意 inventory.ini 及 ansible/conf/tikv.yml 的相關配置。
4、tidb 伺服器視業務類型，如果業務邏輯有偏 AP 類的 sql，需要考慮配置大內存，防止出現 OOM。
如果是純 TP 類業務，tidb 伺服器 CPU 配置較高的話喚型，也可以考慮多實例部署，每個 tidb-server 分配20~32core，可以避免無謂的CPU上下文切換， 減少 system cpu 消耗。
5、pd 伺服器的磁碟可以配置200~500G 的SSD 盤，主要用來保存源數據信息。在集群規模較大，源數據信息較多的和羨猜時候，SSD 磁碟能夠避免源數據信息存取成為集群的瓶頸點。
1、操作系統版本要求
建議 centos 7.3及以上，支持 redhat 7.3版本及以上，不推薦其他版本的系統。
2、ansible、jinja 等軟體依賴包版本，只需要驗證中控機（運行ansible 機器）上軟體版本滿足條件即可
中控機：
監控機（grafana）：
3、測試環境磁碟 IO 不滿足需求
ansible-playbook bootstrap.yml --extra-vars "dev_mode=True"
加上 dev_mode=True 可以在部署時，繞過系統磁碟相關的 benchmark
4、關閉防火牆、開啟時鍾同步
systemctl status firewalld
systemctl status chronyd/ntpd
5、集群下所有伺服器要配置不同的 hostname
如果否，可以編輯 inventory.ini 的配置項 set_hostname=True 來自動修改 hostname
6、調整參數
參數在 ansible/conf/目錄下，tidb.yml，tikv.yml，常見的可能需要調整的參數
tidb.yml：
grpc-connection-count: 如果伺服器 CPU 配置較高，tikv 實例個數較多，該參數可以調整至20~32之間
slow-threshold：slow-query 記錄的閾值，默認300ms
level：日誌級別，默認 info，可以視情況調整為 debug 或 error
tikv.yml：
sync-log：raft-log sync配置，默認值true，對於磁碟 io 消耗較高，測試/非金融生產環境建議設置為 false
region-split-check-diff：檢測 region 分裂的閾值，非 SSD 磁碟建議調大至32MB
rocksdb defaultcf block-cache-size(GB) = MEM * 80% / TiKV 實例數量 * 30%（多實例部署下配置，單實例部署不需要修改）
rocksdb writecf block-cache-size(GB) = MEM * 80% / TiKV 實例數量 * 45%（多實例部署下配置，單實例部署不需要修改）
rocksdb lockcf block-cache-size(GB) = MEM * 80% / TiKV 實例數量 * 2.5% (最小 128 MB)（多實例部署下配置，單實例部署不需要修改）
raftdb defaultcf block-cache-size(GB) = MEM * 80% / TiKV 實例數量 * 2.5% (最小 128 MB)（多實例部署下配置，單實例部署不需要修改）
多實例情況下，需要修改
readpool:
coprocessor:
high-concurrency
normal-concurrency
low-concurrency
三個參數，推薦為實例數*參數值 = CPU 核數 * 0.8。
raftstore:
capacity
磁碟總容量 / TiKV 實例數量，例如 「100GB」
修改完後，可以使用下面命令驗證
cat tidb-ansible/conf/tikv.yml |grep -Ev "^$|#"
無誤後執行
ansible-playbook rolling_update.yml --tags=tidb/tikv
滾動升級，tags 可選
7、官網有比較完善的在線+離線部署方案、在線升級指導、在線擴容縮容文檔，具體參考：
https://pingcap.com/docs-cn/op-guide/ansible-deployment/
https://pingcap.com/docs-cn/op-guide/offline-ansible-deployment/
https://pingcap.com/docs-cn/op-guide/ansible-deployment-scale/
1、從 MySQL 遷移
TiDB 兼容 MySQL 語法，小數據量建議直接使用 mysqlmp、mymper 來全量導出數據，再通過 source、myloader 的方式導入 TiDB。
./bin/mymper -h 127.0.0.1 -P 3306 -u root -t 16 -F 64 -B test -T t1,t2 --skip-tz-utc -o ./var/test
./bin/loader -h 127.0.0.1 -u root -P 4000 -t 32 -d ./var/test
詳情請參考： https://pingcap.com/docs-cn/op-guide/migration/#使用-mymper-loader-全量導入數據
如果數據量較大，超過幾百 G，可以聯系原廠申請試用 lightning 工具，loader 導入數據平均速度是20G/小時，lightning 約為100~150G/小時
2、從 Oracle 遷移
目前有幾種方式可以參考
使用 OGG 做全量+增量同步
使用 Navicat Premium 版的 data transfer 功能，支持從 Oracle/SqlServer 遷移全量數據至 TiDB
通過 kafka 等消息隊列工具，解析 OGG 的日誌，開發寫入 TiDB/MySQL 的工具
目前我們也在積極跟專業的數據異構平台合作，爭取能夠盡快在更多的數據遷移工具中兼容 TiDB 數據源。
1、啟動集群
ansible-playbook start.yml --tags=tidb/tikv/pd
在正確的 ansible 目錄下，確保 inventory.ini 里的配置正確，tags 可選
2、停止集群
ansible-playbook stop.yml --tags=tidb/tikv/pd
在正確的 ansible 目錄下，確保 inventory.ini 里的配置正確，tags 可選
3、停止單個 tidb-server / tikv-server
ansible-playbook stop.yml --tags=tidb/tikv/pd -l IP
-l 後面接 inventory.ini 配置的IP 或別名
4、訪問 tidb
TiDB 兼容 MySQL 協議，所有連接 MySQL 的方式都適用於TiDB
mysql -uroot -h127.0.0.1 -P4000 -p
常見的圖形化界面工具，navicat 等都可以直接訪問 tidb
同時也支持jdbc、odbc 等，需要注意的是 mysql 8.0版本的客戶端，及 mariadb 客戶端可能存在兼容性問題，不建議使用
SQL 語法基本兼容 MySQL，某些不兼容的場景見： https://pingcap.com/docs-cn/sql/mysql-compatibility/#與-mysql-兼容性對比
5、修改參數
可以通過修改 tidb-ansible/conf/tidb.yml 配置文件，然後執行
ansible-playbook rolling_update.yml --tags=tidb/tikv
也可以直接登錄伺服器，找到deploy_dir/conf/tidb.toml，直接編輯文件，然後 pkill tidb-server 來重啟服務
6、查看 tidb 版本信息
select tidb_version();
Release Version: v2.1.0-rc.3-24-g23f90a6
Git Commit Hash:
Git Branch: HEAD
UTC Build Time: 2018-10-10 09:18:39
GoVersion: go version go1.11 linux/amd64
Race Enabled: false
TiKV Min Version: 2.1.0-alpha.1-
Check Table Before Drop: false
7、備份 tidb 數據
全量備份可以採用 mymper，增量備份需要開啟 binlog，實時恢復採用商業版工具 reparo。
8、查看監控數據
在 ansible 的配置文件 inventory.ini 里，有一個監控伺服器的配置
[monitoring_servers]
10.1.163.87
deploy 的時候會默認在這個配置伺服器上部署 grafana 組件，通過
http://10.1.163.87:3000 admin/admin 訪問
具體一些常見的監控指標，請參考： https://pingcap.com/docs-cn/op-guide/dashboard-overview-info/
9、收集統計信息
set @@tidb_build_stats_concurrency=20;
set @@tidb_distsql_scan_concurrency=100;
set @@tidb_index_serial_scan_concurrency=20;
analyze table xxx index xxx;
修改上面三個參數可以提升 scan 效率。
具體統計信息相關，請參考： https://pingcap.com/docs-cn/sql/statistics/#統計信息簡介
1、Transaction too large
TiDB 對於事務有限制，簡單來說以下幾點：
單個事務的SQL 語句數量不能超過5000，（ 在 tidb.yml 可配 stmt-count-limit ）
單條 KV entry 不超過 6MB
KV entry 的總條數不超過 30w
KV entry 的總大小不超過 100MB
備註：假設某張表有4個索引，那麼一條數據對應的 kv entry 為數據+索引，一共5個kv 記錄。
如果是批量 insert 或delete，建議先修改
set tidb_batch_insert = 1;
set tidb_batch_delete = 1;
update mysql.tidb set variable_value='24h' where variable_name='tikv_gc_life_time';
再執行 SQL。
如果是批量 update，建議採用 limit 循環的方式執行。
2、GC life time is shorter than transaction ration
GC Life Time 間隔時間過短，長事務本應讀到的數據可能被清理了，可使用如下命令增加 GC Life Time ：
update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time';
3、Lost connection to MySQL server ring query
log 中是否有 panic
dmesg 中是否有 oom，命令： dmesg -T | grep -i oom
長時間沒有訪問，也會收到這個報錯，一般是 tcp 超時導致的，tcp 長時間不用, 會被操作系統 kill。
㈣ tidb的數據類型查詢問題
tidb對於類型要橡肢求比較嚴格，例如 varchar 存液如芹儲的欄位內容，查詢時用整形查，tidb會先轉化類型後再查詢，鬧畢速度超級慢
id int(11) primary key
advertiser_id varchar(32) not null
advertiser_id 存儲的都是 123，445，666之類
select * from table where name in (445,666) 這樣查詢會很慢
select * from table where name in ('445','666') 數據類型一致時會很快
㈤ 國內重要的 Go 語言項目：TiDB 3.0 GA，穩定性和性能大幅提升
TiDB 是 PingCAP 自主研發的開源分布式關系型資料庫，具備商業級資料庫的數據可靠性，可用性，安全性等特性，支持在線彈性水平擴展，兼容 MySQL 協議及生態，創新性實現 OLTP 及 OLAP 融合。
TiDB 3.0 版本顯著提升了大規模集群的穩定性，集群支持 150+ 存儲節點，300+TB 存儲容量長期穩定運行。易用性方面引入大量降低用戶運維成本的優化，包括引入 Information_Schema 中的多個實用系統視圖、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特別是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升約 4.5 倍，Sysbench 性能提升約 1.5 倍，OLAP 方面，TPC-H 50G Q15 因實現 View 可以執行，至此 TPC-H 22 個 Query 均可正常運行。新功能方面增加了窗口函數、視圖（實驗特性）、分區表、插件系統、悲觀鎖（實驗特性）。
截止本文發稿時 TiDB 已在 500+ 用戶的生產環境中長期穩定運行，涵蓋金融、保險、製造，互聯網， 游戲 等領域，涉及交易、數據中台、 歷史 庫等多個業務場景。不同業務場景對關系型資料庫的訴求可用 「百花齊放」來形容，但對關系資料庫最根本的訴求未發生任何變化，如數據可靠性，系統穩定性，可擴展性，安全性，易用性等。請跟隨我們的腳步梳理 TiDB 3.0 有什麼樣的驚喜。
3.0 與 2.1 版本相比，顯著提升了大規模集群的穩定性，支持單集群 150+ 存儲節點，300+TB 存儲容量長期穩定運行，主要的優化點如下：
1. 優化 Raft 副本之間的心跳機制，按照 Region 的活躍程度調整心跳頻率，減小冷數據對集群的負擔。
2. 熱點調度策略支持更多參數配置，採用更高優先順序，並提升熱點調度的准確性。
3. 優化 PD 調度流程，提供調度限流機制，提升系統穩定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時間，提升系統穩定性。
眾所周知，資料庫查詢計劃的穩定性對業務至關重要，TiDB 3.0 版本採用多種優化手段提升查詢計劃的穩定性，如下：
1. 新增 Fast Analyze 功能，提升收集統計信息的速度，降低集群資源的消耗及對業務的影響。
2. 新增 Incremental Analyze 功能，提升收集單調遞增的索引統計信息的速度，降低集群資源的消耗及對業務的影響。
3. 在 CM-Sketch 中新增 TopN 的統計信息，緩解 CM-Sketch 哈希沖突導致估算偏大，提升代價估算的准確性，提升查詢計劃的穩定性。
4. 引入 Skyline Pruning 框架，利用規則防止查詢計劃過度依賴統計信息，緩解因統計信息滯後導致選擇的查詢計劃不是最優的情況，提升查詢計劃的穩定性。
5. 新增 SQL Plan Management 功能，支持在查詢計劃不準確時手動綁定查詢計劃，提升查詢計劃的穩定性。
1. OLTP
3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優化點如下：
1. TiDB 持續優化 SQL 執行器，包括：優化 NOT EXISTS 子查詢轉化為 Anti Semi Join，優化多表 Join 時 Join 順序選擇等。
2. 優化 Index Join 邏輯，擴大 Index Join 運算元的適用場景並提升代價估算的准確性。
3. TiKV 批量接收和發送消息功能，提升寫入密集的場景的 TPS 約 7%，讀密集的場景提升約 30%。
4. TiKV 優化內存管理，減少 Iterator Key Bound Option 的內存分配和拷貝，多個 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存儲引擎插件，提升 Value 值超過 1KB 時性能，緩解 RocksDB 寫放大問題，減少磁碟 IO 的佔用。
6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節點內可擴展性，進而提升單節點內並發處理能力和資源利用率，降低延時，大幅提升集群寫入能力。
TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優化點，如下：
1. 提升 SQL 轉化成 KV Pairs 的性能，減少不必要的開銷。
2. 提升單表導入性能，單表支持批量導入。
3. 提升 TiKV-Importer 導入數據性能，支持將數據和索引分別導入。
4. TiKV-Importer 支持上傳 SST 文件限速功能。
RBAC（Role-Based Access Control，基於角色的許可權訪問控制） 是商業系統中最常見的許可權管理技術之一，通過 RBAC 思想可以構建最簡單「用戶-角色-許可權」的訪問許可權控制模型。RBAC 中用戶與角色關聯，許可權與角色關聯，角色與許可權之間一般是多對多的關系，用戶通過成為什麼樣的角色獲取該角色所擁有的許可權，達到簡化許可權管理的目的，通過此版本的迭代 RBAC 功能開發完成。
IP 白名單功能（企業版特性） ：TiDB 提供基於 IP 白名單實現網路安全訪問控制，用戶可根據實際情況配置相關的訪問策略。
Audit log 功能（企業版特性） ：Audit log 記錄用戶對資料庫所執行的操作，通過記錄 Audit log 用戶可以對資料庫進行故障分析，行為分析，安全審計等，幫助用戶獲取數據執行情況。
加密存儲（企業版特性） ：TiDB 利用 RocksDB 自身加密功能，實現加密存儲的功能，保證所有寫入到磁碟的數據都經過加密，降低數據泄露的風險。
完善許可權語句的許可權檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句許可權檢查。
1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢日誌內容，如：Coprocessor 任務數，平均/最長/90% 執行/等待時間，執行/等待時間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產品易用性。
2. 新增系統配置項合法性檢查，優化系統監控項等，提升產品易用性。
3. 新增對 TableReader、IndexReader 和 IndexLookupReader 運算元內存使用情況統計信息，提高 Query 內存使用統計的准確性，提升處理內存消耗較大語句的效率。
4. 制定日誌規范，重構日誌系統，統一日誌格式，方便用戶理解日誌內容，有助於通過工具對日誌進行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調優的易用性。
6. 新增 SQL 語句 Trace 功能，方便排查問題。
7. 新增通過 unix_socket 方式連接資料庫。
8. 新增快速恢復被刪除表功能，當誤刪除數據時可通過此功能快速恢復數據。
TiDB 3.0 新增 TiFlash 組件，解決復雜分析及 HTAP 場景。TiFlash 是列式存儲系統，與行存儲系統實時同步，具備低延時，高性能，事務一致性讀等特性。 通過 Raft 協議從 TiKV 中實時同步行存數據並轉化成列存儲格式持久化到一組獨立的節點，解決行列混合存儲以及資源隔離性問題。TiFlash 可用作行存儲系統（TiKV）實時鏡像，實時鏡像可獨立於行存儲系統，將行存儲及列存儲從物理隔離開，提供完善的資源隔離方案，HTAP 場景最優推薦方案；亦可用作行存儲表的索引，配合行存儲對外提供智能的 OLAP 服務，提升約 10 倍復雜的混合查詢的性能。
TiFlash 目前處於 Beta 階段，計劃 2019 年 12 月 31 日之前 GA，歡迎大家申請試用。
未來我們會繼續投入到系統穩定性，易用性，性能，彈性擴展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗，極致的用戶體驗。
穩定性方面 V4.0 版本將繼續完善 V3.0 未 GA 的重大特性，例如：悲觀事務模型，View，Table Partition，Titan 行存儲引擎，TiFlash 列存儲引擎；引入近似物理備份恢復解決分布資料庫備份恢復難題；優化 PD 調度功能等。
性能方面 V4.0 版本將繼續優化事務處理流程，減少事務資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。
彈性擴展方面，PD 將提供彈性擴展所需的元信息供外部系統調用，外部系統可根據元信息及負載情況動態伸縮集群規模，達成節省成本的目標。
我們相信戰勝「未知」最好的武器就是社區的力量，基礎軟體需要堅定地走開源路線。截止發稿我們已經完成 41 篇源碼閱讀文章。TiDB 開源社區總計 265 位 Contributor，6 位 Committer，在這里我們對社區貢獻者表示由衷的感謝，希望更多志同道合的人能加入進來，也希望大家在 TiDB 這個開源社區能夠有所收獲。
TiDB 3.0 GA Release Notes： https://pingcap.com/docs-cn/v3.0/releases/3.0-ga/
㈥ TiDB 集群的可用性詳解及 TiKV Label 規劃
目 錄
一、前言
二、TiDB 集群核心組件可用性概覽
1. TiDB Server 的可用性
三、Multi-Raft 集群的可用性限制
1. Raft 簡介
2. Raft Group 副本數的選擇
3. PD 是單一 Raft Group
4. TiKV 是 Multi-Raft 系統
5. Multi-Raft 集群的可用性限制
四、規劃 TiKV Label 以提升 TiKV 集群的可用性
1. TiKV Label 簡介
2. Label 相關的 PD 調度策略解讀
3. TiKV Label 的規劃
4. 使用 Label 的注意事項
五、典型兩地三中心跨中心高可用多活容災備配置
1. 物理伺服器主機配置
2. 伺服器，機櫃，機房，網路要求
3. 兩地三中心集群的擴容策略
分布式系統的核心理念是讓多台伺服器協同工作，完成單台伺服器無法處理的任務。單點的硬體和網路等都是不可靠的，想要提高硬體的可靠性需要付出大量的成本，因此分布式系統往往通過軟體來實現對於硬體的容錯，通過軟體來保證整體系統的高可靠性。
TiDB 集群中包含了串-並聯系統，表決系統等，相對於一般的分布式系統更為復雜，TiDB 中所保存的數據的可用性由諸多因素控制，通過本篇文章的介紹，您可以了解到怎樣在給定的資源下設計部署架好頃皮構以盡可能地提高數據的可用性。
在 TiDB 集群的三個核心組件 PD，TiKV，TiDB 中，PD 和 TiKV 都採用 Raft 協議實現持久化數據的容災以及自動的故障轉移，有關 PD 和 TiKV 的可用性的詳細解讀，請參見第三章的內容。
TiDB Server 組件不涉及數據的持久化，因此 TiDB 被設計成了無狀態的，TiDB 進程可以在任意位置被啟動，多個 TiDB 之間的關系是對等的，並發的事務通過同一台 TiDB 發送給集群和通過多台 TiDB 發送給集群所表現的行為完全一致。單一 TiDB 的故障只會影響這個 TiDB 上當前的連接，對其他 TiDB 上的連接沒有任何影響。
根據用戶最佳實踐，在 TiDB 之上一般會部署負載均衡器（F5，LVS，HAproxy，Nginx 等），因此負載均衡器所連接的 TiDB 越多，其整體可用性就越高，其整體所能承載的並發請求數量也越多。
在使用負載均衡器的場景下，建議使用的負載均衡演算法為 least connection，當某個 TiDB 發生故障依然會導致當時連接到該 TiDB 上的請求失敗，負載均衡器識別到 TiDB 的故障之後，將不再向此 TiDB 建立新的連接，而是將新的連接建立到可用的 TiDB 上，以此來實現整體的高可用。
Raft 是一種分布式一致性演算法，在 TiDB 集群的多種組件中，PD 和 TiKV 都通過 Raft 實現了數據的容災。Raft 的災難恢復能力通過如下機制實現：
Raft 演算法本身以及 TiDB 中的 Raft 實現都沒有限制一個 Raft Group 的副本數，這個副本數可以為任意正整數，當副本數為 n 的時候，一個 Raft Group 的可靠性如下：
我們一般建議將 Raft Group 的副本數設置為奇數，其原因如下：
在一般的非關鍵業務場景乎旅下，建議將副本數選為 3；而在關鍵業務中建議將副本數選為 5。
遵循 Raft 可靠性的特點，放到現實場景中：
PD 集群只包含一個 Raft Group，即 PD 集群中 PD 服務的個數決定了 PD 的副本數，3 PD 節點集群的 PD 副本數為 3，5 PD 節點集群的 PD 副本數為 5。
由上一段落中 Raft 原理可知，一個 Raft Group 的容災能力隨節點數增加而加強，在一般的非關鍵業務場景下，建議部署 3 個 PD；建議在關鍵業務中部署 5 個 PD。
TiKV 是一個 Key-Value 存儲系友差統，它是一個巨大的 Map，TiKV 提供有序遍歷方法。下圖展示了 region 以 3 副本模式存儲在 4 台 TiKV 節點上的數據分布，TiKV 中的數據被切分成了 5 份 —— region 1~5，每個 region 的 3 個副本構成了一個 Raft Group，集群中共有 5 個 Raft Group，因此 TiKV 是 Multi-Raft 系統。
如上圖所展示，雖然這個集群當前有 4 個 TiKV 實例，但一個 region 的 3 個副本只會被調度到其中 3 個 TiKV 上，也就是說 region 的副本數與 TiKV 實例數量無關，即使將上圖的集群擴容到 1000 個 TiKV 實例，它也仍然是一個 3 副本的集群。
前面說到 3 副本的 Raft Group 只能容忍 1 副本故障，當上圖的集群被擴容到 1000 個 TiKV 實例時，這個集群依然只能容忍一個 TiKV 實例的故障，2 個 TiKV 實例的故障可能會導致某些 region 丟失多個副本，整個集群的數據也不再完整，訪問到這些 region 上的數據的 SQL 請求將會失敗。
而 1000 個 TiKV 中同時有兩個發生故障的概率是遠遠高於 3 個 TiKV 中同時有兩個發生故障的概率的，也就是說 Multi-Raft 集群在逐步擴容中，其可用性是逐漸降低的。
TiKV Label 用於描述 TiKV 的位置信息，在 inventory.ini 中，其寫法如下：
上面案例中規劃了 4 層位置信息的 Label，Label 信息會隨著 deploy.yml 或 rolling_update.yml 操作刷新到 TiKV 的啟動配置文件中，啟動後的 TiKV 會將自己最新的 Label 信息上報給 PD，PD 根據用戶登記的 Label 名稱（也就是 Label 元信息），結合 TiKV 的拓撲進行 region 副本的最優調度。用戶可以根據自己的需要來定製 Label 名稱，以及 Label 層級（注意層級有先後順序），但需要注意 PD 會根據它讀到的 Label 名稱（含層級關系）去匹配 TiKV 的位置信息，如果 PD 讀到的 TiKV Label 信息與 PD 中設置的 Label 名稱不匹配的話，就不會按用戶設定的方式進行副本調度。Label 名稱的設置方法如下，在初次啟動集群時，PD 會讀取 inventory.ini 中的設置：
非初次啟動的集群，需要使用 pd-ctl 工具進行 Label 名稱設置：
從本質上來說，Label 系統是一種 PD 對 region 副本（replica）的隔離調度策略。
PD 首先讀取到集群的 region 副本數信息*，假定副本數為 5。PD 將所有 TiKV 匯報給它的 Label 信息進行匯總（以本章第 1 小節的 TiKV 集群為例），PD 構建了整個 TiKV 集群的拓撲，其邏輯如下圖所示：
PD 識別到第一層 Label - dc 有 3 個不同的值，無法在本層實現 5 副本的隔離。PD 進而判斷第二層 Label - zone，本層有 z1~z5 這 5 個 zone，可以實現 5 副本的隔離調度，PD 會將各個 region 的 5 個副本依次調度到 z1~z5 中，因此 z1~z5 各自所對應的 4 個 TiKV 所承載的 region 數量總和應完全一致。此時，PD 的常規調度策略，如 balance-region，hot-region 等 region 相關的 scheler 將嚴格遵守 Label 的隔離策略進行調度，在帶有 z1~z5 Label 信息的 TiKV 尚在的情況下不會將同一個 region 的多個副本調度到同一個 zone 中。如圖，圖中將 TiKV 按照 zone 做 4 個一組隔離開了，一個 region 的一個副本只會在本 zone 的 4 個 TiKV 之間調度。
PD 天生不會將同一個 region 的多個副本調度到同一個 TiKV 實例上，增加 Label 信息後，PD 不會將同一個 region 的多個副本調度到同一個 host 上，以避免單台伺服器的宕機導致丟失多個副本。
當帶有某一個 zone Label 的 TiKV 全部故障時，如圖中所有帶有 z5 Label 的幾個 TiKV 實例 kv252-1，kv252-2，kv253-1，kv253-2 同時故障時，集群會進入缺失一個副本的狀態，在達到 TiKV 最大離線時間的設置值（max-store-down-time，默認值 30min）之後，PD 便開始在其他 4 個 zone 中補全所有缺失副本的 region，同時遵循上面一段所提到的約束，在為 region1 補全副本時，PD 會避開所有包含 region1 的伺服器（本例中的 host）h208，h210，h414，h416 所涉及的 8 個 TiKV 實例，而在另外 8 個 TiKV 實例中挑選一個進行副本補全調度。
*副本數設置方法如下，以 5 副本為例：
Label 登記的是 TiKV 的物理位置信息，PD 根據 TiKV 的物理位置進行最優調度，其目的是在具有相近物理位置的 TiKV 上只放置一個副本，以盡可能的提高 TiKV 集群的可用性。舉個例子，假設某一時刻集群中一定要有兩個 TiKV 同時發生故障，那麼你一定不想它們上面存儲著一個 region 的兩個副本，而通過合理規劃讓同時故障的兩個 TiKV 出現在同一個隔離區的概率變高，TiKV 集群的整體可用性也就越高。因此 Label 規劃要與 TiKV 物理位置規劃一起進行，兩者是相輔相成的。
舉例而言，機房可能會由於電源故障，空調故障，網路故障，火災，自然災害等原因而整體不可用；機櫃可能由於交換機故障，UPS 故障，消防噴淋等原因而整體不可用；伺服器可能由於常見的內存等故障而宕機。通過妥善的 Label 規劃，使 region 調度按物理位置進行隔離，可以有效地降低一個區域故障造成的整體影響。
物理位置的層級結構一般為機房，機櫃，伺服器，在大型基礎設施中還會在機房與機櫃之間多一個樓層信息。設計 Label 層級結構的最佳實踐是基於物理層級結構再加上一層邏輯層級，該邏輯層級專門用於控制保持與集群副本數一致，在本案例中，zone 就是邏輯層級，該層級的值在集群搭建初期與 rack 保持一一對應，用於控制副本的隔離。而不直接採用 dc，rack，host 三層 Label 結構的原因是考慮到將來可能發生 rack 的擴容（假設新擴容的 rack 編號是 r6，r7，r8，r9，r10），這個擴容會導致 rack 數變多，當多個 TiKV 實例同時發生故障時，這些故障的 TiKV 出現在在多個 rack 上的概率也會增加，也就是會將第三章提到的 Multi-Raft 集群的可用性隨節點數增加而下降問題再次引入到集群中。而通過使用邏輯層級 zone 保持與副本數一致可以將多個故障的 TiKV 出現在不同的隔離區（本例中的 zone）的概率降至最低，將來擴容 rack 也可以充分的利用到更多的 rack 的物理隔離來提高可用性。
在使用了 Label 隔離的集群中，存在以下限制：
規劃了 Label 的集群再擴容時需要對每個隔離區進行容量一致的擴容，在本章的案例中，隔離區為 dc 和 rack 標示的位置，因此需要對每種 dc+rack 組合的區域進行容量一致的擴容，比如將要擴容 5 台 TiKV 伺服器，其分配方法如下：
zone1=>dc1:rack1 增加一台 TiKV
zone2=>dc1:rack2 增加一台 TiKV
zone3=>dc2:rack1 增加一台 TiKV
zone4=>dc2:rack2 增加一台 TiKV
zone5=>dc3:rack1 增加一台 TiKV**
㈦ 在 ARM64 上面運行 TiDB
相比於 Intel 的 x86-64 架構，ARM 架構雖然作為後來者，但在伺服器領域也開始在不停慶頌地攻城拔寨，很多企業也開始將自己的服務遷移到 ARM 架構上面，自然，對於 TiDB 來說，大家也想將 TiDB 運行到 ARM 上面。因為 AWS 上面直接提供了 ARM 機型，所以我們決定先嘗試在 AWS 的 ARM 上面編譯運行 TiDB。
TiDB 主要包含三個組件 - PD，TiKV 和 TiDB，對於 PD 和 TiDB 來說，使用的是 Go 進行編譯的，所以我們只需要在 ARM 機器上面裝好 Go 的版本就可以了。這里，我使用的是 go1.12.6.linux-arm64 這個版本。
用 Go 編譯 TiDB 和 PD 比較容易，中途遇到了一個 TiDB 的編譯問題，只需要升級下 vendor 就解決了。
編譯 TiKV 就比較麻煩了，因為我們使用的是 CentOS 系統，系統用 yum 就能安裝相關的依賴，除了 cmake3 ，裝 cmake 需要做如下處理：
當然，編譯 RocksDB 還有 Titan 的時候還遇到了一些錯誤，不過多數就是傳遞編譯參數的時候需要處理下 ARM64 相關的選項，並不是特別的困難。
總的來說，編譯並沒有花太多的時間，這里有一個 腳本 ，大家可以自行去看如何在 ARM64 上面編譯 TiDB。對於運行集群需要的 Grafana 和 Prometheus，官方都提供了 ARM64 版本，大家可以直接去 Google。
編譯好了 ARM64 的版本，自然就是測試了，這里我使用了 go-ycsb 進行了簡單的測試，這里我使用的是 16c32g 的 ARM64 機器，順帶也開了一台同配置的 x86 作為對比。
在每台測試機器上面，啟動一個 PD，一個 TiKV，使用的是默認配置，然後 go-ycsb 使用 100 並發，導入 1 百萬數據，操作次數 1 百萬，batch size 為 0。
結果如下：
可以看到，ARM 的機器性能比 x86 的差了很多，需要來優化了。在網上找了這篇 文章 ，使用了上面的腳本，但發現沒有什麼變化。在這個腳本裡面，主要的優化就是將網卡中斷的處理綁定到某一個 CPU 上面，然後將 RPS 分散到不同的 CPU。對於 16c32g 的機器來說，這個腳本將網卡中斷的處理綁定到 CPU core 0 和 8 上面，然後把 RPS 分散到所有的 CPU 上面，但是我通過 mpstat 發現，core 0 和 8 幾乎被打滿：
於是我重新調了下，將 RPS 分散到除開 core 0 和 8 的地方：
然後 OPS 稍微提升了一點，但 CPU core 0 和 8 仍然是瓶頸。而這個瓶頸明顯是網路處理造成的，直觀的優化就是減少網路消息的處理，於是將 batch size 設為 128，可以發現在 ARM 上面性能提升很多，譬如對於 workload C，OPS 能提升到 118270。但即使這樣，CPU core 0 和 8 還是會成為瓶頸。
對比 ARM，x86 下面 CPU 的分配明顯的均勻很多：
所以後面我磨差山們要考慮的事情就是如何讓 ARM 能更好的處理網路消息。
上面簡單的說了一下如何在 ARM 上面瞎中編譯運行 TiDB，以及一些調優策略。個人認為，雖然 ARM 在性能上面還趕不上相同配置的 x86，但低功耗，成本這些是一個非常大的優勢，加上很多不可說的原因，個人認為會有越來越多的企業使用 ARM，所以這塊也會是趨勢。