作者:shangguan86
故障影響
公司所有的TIDB叢集叢集不可用,涉及多個業務線:支付、視訊、資料分析、使用者等多個業務。
業務流量監控圖:

系統負載
備份任開始時間
登入伺服器
df -h
直接夯死
根據cpu負載以及
duration
的時間基本判斷是ceph導緻的問題。
BR備份原理:
TIDB是分布式的資料庫,是以備份也是分布式的。TIDB每天夜晚零晨都會使用TIDB備份元件BR進行一次全量備份;使用BR備份依賴于所有TiKV節點都有一個共享檔案系統詳情如下圖:
使用ceph挂載到tidb的機器做共享檔案。
如下圖所示:
目前TIDB部署架構
IP | 業務部署 |
10.92.xxx.xxx | pd、tidb-server、tikv-20161、tikv-20162、tikv-20163 |
10.93.xxx.xxx | pd、tidb-server、tikv-20161、tikv-20162、tikv-20163 |
10.94.xxx.xxx | pd、tidb-server、tikv-20161、tikv-20162、tikv-20163 |
10.95.xxx.xxx | tikv-20161、tikv-20162、tikv-20163 |
10.96.xxx.xxx | tikv-20161、tikv-20162、tikv-20163 |
排查過程
問題疑問
df -h
直接夯死把機器挂載點解除安裝是否可以解決?
umount -l /data/local_backup
強制解除安裝機器上所有的挂載點,業務方還是無法通路。
排查TIDB相關日志
pd
、
tidb-server
tikv
日志也沒有發現啥有用的報錯資訊。
備份使用的是
/data/local_backup
目錄雖然目錄解除安裝了但相關的檔案句柄是不是一直還在系統裡占用着,把tikv節點重新開機一下是否可以。
tidb 是三副本,是以理論上關閉一個節點對業務上無影響。
Tiup
tiup pingcap公司專門為tidb開發的管理工具。
因tuip需要管理多個叢集,為防止某台管理機當機不可管理;是以将tuip的相關資訊存儲在ceph上,目前ceph不可用tuip也無法,是以隻能退回手動管理。
手動關閉tikv節點:
sudo systemctl stop tikv-20161.service
啟動:
sudo systemctl start tikv-20161.service
啟動報錯:
[2020/10/20 11:17:46.389 +08:00] [FATAL] [server.rs:345] ["failed to create raft engine: RocksDb IO error: While lock file: /data/tidb-data/tikv-20161/raft/LOCK: Resource temporarily unavailable"]
初步懷疑tivk有一個檔案鎖,非正常關閉不會删除檔案鎖。
mv LOCK LOCK_back
在次啟動還是同樣報錯。
再次猜測
有可能是機器上的檔案句柄資源使用完了,檢視檔案句柄配置檔案
cat /etc/security/limits.conf
* soft nofile 655350
* hard nofile 655350
* soft nproc 655350
* hard nproc 655350
檔案句柄非系統預設
檢視本機目前檔案句柄數量
lost |wc -l
直接卡死
在一台非tidb機器執行看一下,非tidb機器執行速度很快 。更加确認是檔案句柄的問題
lsof > /data/lsof.out
經過漫長的等待⌛終于完成了。
wc -l lsof.out
5668031 lsof.out
看看都是那些程序占用了
awk '{print $2}' lsof.out | sort | uniq -c|sort -n
2716581 369001
2919707 369003
解決問題思路
- 先關閉一台tikv上所有tikv節點
- 檢視檔案句柄資料量
- 重新開機tikv節點
- 觀察日志
開始解決問題
關閉Tikv節點
sudo systemctl stop tikv-20161.service
sudo systemctl start tikv-20161.service
啟動後日志沒有滾動,端口、程序,都沒有
檢視tikv-20161.service
cat /etc/systemd/system/tikv-20161.service
[Unit]
Description=tikv service
After=syslog.target network.target remote-fs.target nss-lookup.target
[Service]
LimitNOFILE=1000000
#LimitCORE=infinity
LimitSTACK=10485760
User=tidb
ExecStart=/data/tidb-deploy/tikv-20161/scripts/run_tikv.sh
Restart=always
RestartSec=15s
[Install]
WantedBy=multi-user.target
手動拉取
run_tikv.sh
這個配置檔案是否可行
nohup run_tikv.sh &
手動也無法拉起,端口程序,日志沒有列印
sh -x 檢視腳本卡在了那裡
cat run_tikv.sh
#!/bin/bash
set -e
# WARNING: This file was auto-generated. Do not edit!
# All your edit might be overwritten!
cd "/data/tidb-deploy/tikv-20161" || exit 1
echo -n 'sync ... '
stat=$(time sync || sync)
echo ok
echo $stat
exec bin/tikv-server \"
--addr "0.0.0.0:20161" \"
--advertise-addr "10.92.xxx.xxx:20161" \"
--status-addr "10.92.xxx.xxx:20181" \"
--pd "10.92.xxx.xxx:2379,10.93.xxx.xxx:2379,10.94.xxx.xxx:2379" \"
--data-dir "/data/tidb-xxx/tikv-20161" \"
--config conf/tikv.toml \"
--log-file "/data/tidb-xxx/tikv-20161/log/tikv.log" 2>> "/data/tidb-xxx/tikv-20161/log/tikv_stderr.log"
sync
卡住了
使用指令重新開機試一下:
/data/tidb-deploy/tikv-20161/bin/tikv-server \"
--addr "0.0.0.0:20161" \"
--advertise-addr "10.92.xxx.xxx:20161" \"
--status-addr "10.92.xxx.xxx:20181" \"
--pd "10.92.xxx.xxx:2379,10.92.xxx.xxx:2379,10.92.xxx.xx:2379" \"
--data-dir "/data/tidb-data/tikv-20161" \"
--config /data/tidb-xxx/tikv-20161/conf/tikv.toml \"
--log-file "/data/tidb-xxx/tikv-20161/log/tikv.log"
[2020/10/20 16:02:45.939 +08:00] [FATAL] [server.rs:295] ["lock /data/xxxx/tikv-20160 failed, maybe another instance is using this directory."]
/data/xxxx/tikv-20160
可能被某些檔案正在占用
僵屍程序占用着檔案
kill -s SIGCHLD pid
kill
掉僵屍程序之後在次使用指令啟動
僵屍程序:僵屍程序占用着檔案無法重新開機,處理僵屍程序有兩種方法一種是重新開機作業系統,另一種殺死
kill -s SIGCHLD pid
但也有可能殺死父程序的pid變為
1
此時就無法
kill
隻能重新開機作業系統。
指令重新開機後,日志滾動看着日志是正常tikv列印,注釋掉腳本裡相關
sync
然後在啟動
#!/bin/bash
set -e
# WARNING: This file was auto-generated. Do not edit!
# All your edit might be overwritten!
cd "/data/tidb-deploy/tikv-20161" || exit 1
#echo -n 'sync ... '
#stat=$(time sync || sync)
#echo ok
#echo $stat
exec bin/tikv-server \"
--addr "0.0.0.0:20161" \"
--advertise-addr "10.92.xxx.xxx:20161" \"
--status-addr "10.92.xxx.xxx:20181" \"
--pd "10.92.xxx.xxx:2379,10.92.xxx.xx:2379,10.92.xxx.xx:2379" \"
--data-dir "/data/tidb-data/tikv-20161" \"
--config conf/tikv.toml \"
--log-file "/data/tidb-deploy/tikv-20161/log/tikv.log" 2>> "/data/tidb-deploy/tikv-20161/log/tikv_stderr.log"
sudo systemctl daemon-reload
重新加載
tikv-20161.service
sudo systemctl start tikv-20161.service
- 為了後面還可以使用tiup 進行管理,還是使用
進行啟動systemctl
tikv 可以正常啟動,但這樣做非常不友好,目前正在這個store上的業務業務上會受影響。
是以我們需要在啟動某個節點的時候把該節點上的region進行驅逐
排程region
./pd-ctl -u http://10.92.xxx.xxx:2379
檢視目前所有的tikv節點:
>>store
把 store 1 上的所有 Region 的 leader 從 store 1 排程出去
scheduler add evict-leader-scheduler 1
把對應的 scheduler 删掉,如果不删除store 1 節點不然再被排程region
scheduler remove evict-leader-scheduler-1
業務恢複正常
重新開機完所有tikv節點後業務恢複正常
其它問題
- 理論上 15個節點 關閉3個節點 不會影響正常的請求 當時的表現是關閉3個節點 直接就無法通路了
noleder
官方回複:
由于 grpc 線程卡死,tikv 向 pd 上報的 heardbeat 失敗,pd 此時已有一個 region 遷移的操作,但是隻成功了添加 learner 的操作,後pd 檢查到現在有四個 peer,一個 learner,一個挂掉的,兩個正常的,就把挂掉的幹掉了 。此操作屬于 PD 的預期行為,正在讨論是否需要進行改進
-
Tikv發現資源可用為啥一直建立這麼檔案句柄
官方回複:
lsof 看起來會把 threads 所能通路到的所有 fd 都打出來,也就是說這裡 grep 出來的數量 / 線程數 才是真實的 fd 數量
-
10.20 日 Ceph 卡死時 BR 備份導緻叢集 QPS 掉底問題
官方回複:
BR 發起備份時,tikv 向 ceph 盤建立目錄,導緻 tikv grpc 卡主,最終導緻 TiKV 無響應 QPS 掉底。通過 PD 日志判斷,也符合此推斷此問題 4.0.8 版本修複
-
如果改用 ceph s3 API 是否會存在風險
官方回複:
建議繼續使用 local 模式備份
ceph s3 協定未進行充分測試
目前官方在4.0.8 版本當中修複此問題: issue:https://github.com/tikv/tikv/pull/8891
期待
希望官方對ceph s3 協定納入測試體系
感謝
最後感謝官方在解決問題的過程提供的遠端支援。再次感謝!