天天看點

TIDB備份引發公司所有TIDB叢集不可用

作者:shangguan86​

故障影響

公司所有的TIDB叢集叢集不可用,涉及多個業務線:支付、視訊、資料分析、使用者等多個業務。

業務流量監控圖:

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

系統負載

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

備份任開始時間

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

登入伺服器

​df -h​

​ 直接夯死

根據cpu負載以及 ​

​duration​

​ 的時間基本判斷是ceph導緻的問題。

BR備份原理:

TIDB是分布式的資料庫,是以備份也是分布式的。TIDB每天夜晚零晨都會使用TIDB備份元件BR進行一次全量備份;使用BR備份依賴于所有TiKV節點都有一個共享檔案系統詳情如下圖:

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

使用ceph挂載到tidb的機器做共享檔案。

如下圖所示:

​​

TIDB備份引發公司所有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      

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

解決問題思路

  • 先關閉一台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 檢視腳本卡在了那裡

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

​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​

​ 可能被某些檔案正在占用

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

僵屍程序占用着檔案

​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節點後業務恢複正常

​​

TIDB備份引發公司所有TIDB叢集不可用

​​

其它問題

  • 理論上 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 協定納入測試體系      

感謝

最後感謝官方在解決問題的過程提供的遠端支援。再次感謝!      

繼續閱讀