《TiDB跨版本更新》 --流程概述

作者： Coke

更新背景

原叢集版本過低，運維難度大，決定進行版本更新
經過測試發現，v5.3.0版本相對于v3.0.10版本性能有很大提升
決定将TiDB v3.0.10更新到TiDB v5.3.0

更新方式

本方案采用Dumpling+Lightning+TiDB Binlog的方式進行

【更新方式劃分】大體分為停機更新與不停機更新根據字面意思了解，我們可以根據業務的要求來進行選擇，如果業務允許進行停機更新，那相對來說我們選擇停機更新會更加的安全，快速，如果業務不允許停機的話我們主要選擇就是不停機更新

不停機更新根據官方文檔來看，需要通過特定方式來進行滾動更新滾動更新對于我們來說或許是一個很好的選擇，但問題就是： 1、業務需求復原，我們的復原方案通常需要針對于全備+增量的方式來進行復原，復原進度較慢 2、因版本差距過大的話，連續進行滾動更新，不可控因素增多 3、老版本通常采用Ansible安裝，又想讓新版本适用tiup進行管理，操作起來較為複雜 #因為種種因素原因，最終決定采用Dumpling+Lightning+TiDB Binlog的方式，可以有效的規避一系列繁瑣問題。

擷取相關資訊
建立TiDB v5.3.0的目标叢集
Dumpling對原叢集進行資料導出
Lightning對目标叢集進行資料導入
啟動Drainer進行增量同步
sync-diff-inspector進行資料校驗
搭建復原鍊路
切換業務

詳細過程

一、擷取相關資訊

#針對相容性問題，進行詳細的調查與測試
當從一個早期的 TiDB 版本更新到 TiDB v5.3.0 時，如需了解所有中間版本對應的相容性更改說明，請檢視對應版本的 Release Notes。

二、搭建TiDB v5.3.0的目标叢集

1、編輯拓撲檔案topology.yaml

#混合部署與跨機房部署見官方文檔
tiup cluster template > topology.yaml

vim topology.yaml
#詳細配置資訊參考官方文檔

2、部署TiDB叢集

#-p/-i 二選一
tiup cluster deploy cluster_name v5.3.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

3、啟動TiDB叢集

#新部署叢集預設關閉狀态，需要将其啟動
tiup cluster start cluster_name

4、驗證叢集狀态

tiup cluster display cluster_name

三、Dumpling對原叢集進行資料導出

資料導出工具Dumpling可以把存儲在TiDB/MySQL中的資料導出為SQL或這CSV格式，可以用于完成邏輯上的全量備份或者導出
#适用場景
1、導出資料量小
2、需要導出SQL語句或者CSV的場景，可以在異構資料庫或者系統中進行遷移
3、對于導出效率要求不高，由于需要讀取資料和轉換，是以比起實體導出效率低下
#選擇導出資料的一緻性方式
flush    （執行時會出現一句 flush table with read olck）隻能讀不能寫（鎖全庫）
snapshot （會擷取指定時間戳的一緻性快照并導出）
lock      （備份什麼鎖什麼）
none      （資料穿越）不用
auto      （根據資料庫不同選擇方式，TiDB選擇snapshot  Mysql會選擇flush）

【注意事項】 1、确定原叢集資料量大小，來判斷導出資料所需要的磁盤大小，防止導出資料量過大導緻磁盤容量不夠報錯 2、因為我們後續需要搭建Drainer進行增量同步，是以需要在導出之前進行Pump部署和開啟Binlog 3、為確定導出資料的可用性，判斷導入與導出時間，調長GC時間

1、編寫Dumpling腳本

vim dumpling.sh

#!/bin/bash
nohup ./dumpling -u  -P  -h  --filetype sql -t 8 -o /data/dumpling -r 200000 -F 256MiB > nohup_dumpling.out &

2、執行Dumpling腳本，并觀察日志

sh dumpling.sh
tail -50f nohup_dumpling.out

四、Lightning對目标叢集進行資料導入

TiDB Lightning是TiDB資料庫的生态工具之一，可以将全量資料高速導入到TiDB叢集中
#使用場景
大量新的資料需要迅速導入到TiDB資料庫中
#Lightning流程
（1）啟動Lightning，TiKV會切換到導入模式（他可以對寫入進行優化，并且停止資料的壓縮）
（2）建立schema和表 （就是連接配接到TiDB Server執行DDL語句，建立相關庫和表）
（3）分割表 （将表分成一個一個的，做增量的并行導入，提高效率）
（4）讀取SQL dump （并發的讀取，給轉化成鍵值對）
（5）寫入本地臨時存儲檔案 （将資料轉換成TiDB想通的鍵值對，然後存儲在本地TiKV檔案中）
（6）導入資料到TiKV叢集 （将資料加載到TiKV當中）

（7）檢驗分析
（8）導入完畢退出并且TiKV切換回普通模式

【注意事項】 1、注意sorted-kv-dir目錄大小，防止導入時候磁盤空間不夠 2、若 tidb-lightning 因不可恢複的錯誤而退出（例如資料出錯），重新開機時不會使用斷點，而是直接報錯離開。為保證已導入的資料安全，這些錯誤必須先解決掉才能繼續。使用 tidb-lightning-ctl 工具可以标示已經恢複 3、可以關注progress來檢視剩餘時間與導入效率

1、編輯Lightning配置檔案

vim lightning.toml
#詳細配置檔案檢視官方文檔
https://docs.pingcap.com/zh/tidb/v5.3/tidb-lightning-configuration

2、編輯執行Lightning腳本

vim lightning.sh
#!/bin/bash
nohup ./tidb-lightning -config lightning.toml > nohup-lightning.out &

3、執行Lightning腳本并檢視運作情況

sh lightning.sh
tail -50f tidb-lightning.log
egrep "progress" lightning.log

五、啟動Drainer進行增量同步

TiDB Binlog工具可以收集TiDB資料庫的日志（binlog），并且提供資料同步和準實時備份功能。
#TiDB Binlog流程
（1）PD擷取上遊資料庫TiDB Server的binlog日志
（2）分散寫入到Pump Cluster（裡面有多個Pump元件）（它負責存儲自己接收的binlog，并且按時間順序進行排序）
（3）在由Drainer進行總排序（一個Drainer對應一個下遊資料庫或者存儲日志或者Apache Karka）
#Pump元件用于實時記錄上遊資料庫傳過來的binlog
（1）多個Pump形成一個叢集，可以水準擴容
（2）TiDB通過内置的Pump Client将Binlog分發到各個Pump
（3）Pump負責存儲Binlog，并将Binlog按順序提供給Drainer
#Drainer元件收集Pump元件發送過來的Binlog進行歸并然後進行排序然後發送給下遊資料庫
（1）Drainer負責讀取各個Pump的Binlog，歸并排序後發送到下遊
（2）Drainer支援relay log功能，通過relay log保證下遊叢集的一緻性狀态
（3）Drainer支援将Binlog同步到MySQL、TiDB、Kafka或者本地檔案當中
#TiDB資料庫的Binlog格式
（1）與MySQL Binlog的Row格式類似（按事務送出的順序記錄，并且隻記增删改，記錄每一行的改變）
（2）以每一行資料的變更為最小機關進行記錄
（3）隻有被送出的事務才會被記錄，且記錄的是完整事務
     在Binlog中會記錄主鍵和開始的時間戳
     在Binlog中會記錄送出的時間戳

【注意事項】 1、在導出資料之前要部署好Pump元件和開啟Binlog 2、commit_ts通過dumpling導出資料的目錄的metadata擷取 3、部署完畢檢視Pump、Drainer運作狀态和checkpoint

1、TiDB Binlog叢集監控

Pump狀态

metric名稱	說明
Storage Size	記錄磁盤的總空間大小（capacity），以及可用磁盤空間大小（available）
Metadata	記錄每個Pump的可删除binlog的最大TSO（gc_tso）,以及儲存的binlog的最大的commit tso
Write Binlog QPS by ln	每個Pump接收到的寫binlog請求的QPS
Write Binlog Latency	記錄每個Pump寫binlog的延遲時間
Storage Write Binlog S	Pump寫binlog資料的大小
Storage Write Binlog L	Pump中的storage子產品寫binlog資料的延遲
Pump Storage Error By	Pump遇到的error數量，按照error的類型進行統計
Query TiKV	Pump通過TiKV查詢事務狀态的次數

Drainer狀态

metric名稱	說明
Checkpoint TSO	Drainer已經同步到下遊的binlog的最大TSO對應的時間，通過該名額估算同步延遲時間
Pump Handle TSO	記錄Drainer從各個Pump擷取到binlog的最大TSO對應的時間
Pull Binlog QPS by Pump NodeID	Drainer從每個Pump擷取binlog的QPS
95% Binlog Reach Duration By Pump	記錄binlog從寫入Pump到被Drainer擷取到這個過程的延遲時間
Error By Type	Drainer遇到的error數量，按照error的類型進行統計
SQL Query Time	Drainer在下遊執行SQL的耗時
Drainer Event	各種類型event的數量，event包括（ddl，insert，delete，update，flush，savepoint）
Execute Time	寫入binlog到同步下遊子產品所消耗的時間
95% Binlog Size	Drainer從各個Pump擷取到binlog資料的大小
DDL job Cout	Drainer處理的DDL的數量
Queue Size	Drainer内部工作隊列大小

2、編輯Ansible叢集檔案inventory.ini檔案

#原端叢集由Ansible完成
詳細配置參數參考官方文檔
https://docs.pingcap.com/zh/tidb/v3.0/deploy-tidb-binlog#%E7%AC%AC-3-%E6%AD%A5%E9%83%A8%E7%BD%B2-drainer

3、修改drainer.toml配置檔案

cd /home/tidb/tidb-ansible/conf &&
cp drainer.toml drainer_mysql_drainer.toml &&
vi drainer_mysql_drainer.toml
#配置檔案名命名規則為 ，否則部署時無法找到自定義配置檔案。 但是需要注意 v3.0.0，v3.0.1 的配置檔案命名規則與其餘版本略有不同，為别名_drainer.toml别名_drainer-cluster.toml
詳細參數參考官方文檔
https://docs.pingcap.com/zh/tidb/v3.0/deploy-tidb-binlog#%E7%AC%AC-3-%E6%AD%A5%E9%83%A8%E7%BD%B2-drainer

4、部署Drainer

ansible-playbook deploy_drainer.yml
#單獨建立部署檔案的inventory.ini的需要-i指定

5、啟動Drainer

ansible-playbook start_drainer.yml
#單獨建立部署檔案的inventory.ini的需要-i指定

六、sync-diff-inspector進行資料校驗

sync-diff-inspector 是一個用于校驗 MySQL／TiDB 中兩份資料是否一緻的工具。該工具提供了修複資料的功能（适用于修複少量不一緻的資料）
#主要功能
1、對比表結構和資料
2、如果資料不一緻，則生成用于修複資料的 SQL 語句
3、支援不同庫名或表名的資料校驗
4、支援分庫分表場景下的資料校驗
5、支援 TiDB 主從叢集的資料校驗
6、支援從 TiDB DM 拉取配置的資料校驗

【注意事項】 1、個别資料類型目前不支援比對，需要過濾出來不可比對的列進行過濾掉并進行手工比對 2、對于 MySQL 和 TiDB 之間的資料同步不支援線上校驗，需要保證上下遊校驗的表中沒有資料寫入，或者保證某個範圍内的資料不再變更 3、支援對不包含主鍵或者唯一索引的表進行校驗，但是如果資料不一緻，生成的用于修複的 SQL 可能無法正确修複資料 4、snapshot配置通過checkpoint獲得

1、擷取ts-map

select * from tidb_binlog.checkpoint;

2、編輯sync-diff-inspector

vim sync-diff-inspector.toml
#詳細配置參數參考官方文檔

https://docs.pingcap.com/zh/tidb/v5.3/sync-diff-inspector-overview

3、建立sync-diff-inspector啟動腳本

vim sync-diff-inspector.sh

#!/bin/bash
nohup ./sync-diff-inspector --config=./sync-diff-inspector.toml > nohup_sync-diff-inspector.out &

4、運作sync-diff-inspector腳本

sh sync-diff-inspector.sh

七、搭建復原鍊路

復原鍊路通過TiDB Binlog來完成
#反向搭建一套TiDB Binlog來完成業務的復原

【注意事項】 1、復原鍊路的Binlog與Pump需要在搭建叢集時候同步搭建 2、隻需要配置好Drainer擴容檔案即可，需要復原時在擴容上去

更新總結

#相對于v3.0.10版本，v5.4.0版本性能上更加穩定，運維起來也更加友善
  針對于這種跨版本的資料庫更新，我相信它會是一種操作比較多也是比較重要的項目。在這裡隻是簡單的介紹了方法的流程與步驟
具體的操作執行，還需要自己進行相應的測試，畢竟對于我們來說，安全、穩定更為重要。
#有幾個地方是我們需要值得注意的：
1、Dumpling導出資料之前一定要開啟Pump和Drainer
2、Dumpling導出資料之前GC時間要進行調整
3、Lightning導入資料會有部分由于版本差距過大導緻的不相容問題，盡量提前測試提前進行避免
4、sync-diff-inspector資料校驗，針對于不支援的列提前找出并過濾，進行手工比對
5、記着擷取原叢集的使用者資訊導入到目标叢集
6、復原鍊路隻需要配置好檔案在切換業務時候擴容即可
7、需求復原之時把原業務反向切換

《TiDB跨版本更新》 --流程概述

更新背景

更新方式

詳細過程

一、擷取相關資訊

二、搭建TiDB v5.3.0的目标叢集

三、Dumpling對原叢集進行資料導出

四、Lightning對目标叢集進行資料導入

五、啟動Drainer進行增量同步

六、sync-diff-inspector進行資料校驗

七、搭建復原鍊路

更新總結

繼續閱讀

Kafka：Topic概念與API介紹

5G小型蜂應用指南

PAT (Advanced Level) Practise 1012 The Best Rank (25)

mysql5.7的sql優化

線程通信和程序通信差別（線程程序差別）

Matlab随機波動率SV、GARCH用MCMC馬爾可夫鍊蒙特卡羅方法分析匯率時間序列

微信小程式前端解密擷取使用者資訊

Spring MVC 自學雜記（五） -- SpringMVC與前台的json資料互動

《MySQL技術内幕：InnoDB存儲引擎》筆記

擴容TIKV節點遇到的坑

PHP輔導代做程式設計：CS353 Database System

自學Zabbix3.10.2-事件通知Notifications upon events-Actions報警配置點選傳回：自學zabbix集錦

HDU 5678 ztr loves trees

拓端tecdat|R語言彈性網絡Elastic Net正則化懲罰回歸模型交叉驗證可視化

二叉樹及其應用--二叉樹建立

詳解STM32單片機的堆棧