K8S Pod异常情况下pd如何强制指定leader

Min_Chen · 2022 年7 月 6 日 03:11

进到 pd leader 的容器执行一下

/pd-ctl -u http://127.0.0.1:2379 region key --format=encode "mBootstra\\xffpKey\\x00\\x00\\x00\\x00\\xfb\\x00\\x00\\x00\\x00\\x00\\x00\\x00s"

结果贴给我

realcp1018 · 2022 年7 月 6 日 03:27

结果就只有null这个单词

现在那14个缺失peer的还在，没有自动补齐，operator show也没有东西

realcp1018 · 2022 年7 月 6 日 03:43

tikv-ctl raw-scan的结果出来了，显示有30个key

Min_Chen · 2022 年7 月 6 日 05:56

看下去其他 pd 能解出来吗？

scheduler show 看下 scheduler 齐全吗？
看下节点和 pv 的磁盘余量充足吗？
再在监控看下 pd 调度相关的，可以发上来一起看，操作方法参考 PingCAP MetricsTool
再看下 pd leader 日志，tikv 日志。

realcp1018 · 2022 年7 月 6 日 06:38

现在正常了，是pd调度之前关掉了，忘记了做什么操作的时候关掉的。
目前miss-peer都补全了。
其他2个pd的输出也是null。

Min_Chen · 2022 年7 月 6 日 06:42

现在 tidb-server 可以正常启动了吗？

有没有 tidb-server 和 tikv-client 同时使用了这个集群的情况？

realcp1018 · 2022 年7 月 6 日 06:47

刚才重启了tidb 还是只有如下DEBUG信息：

[2022/07/06 14:40:59.119 +08:00] [DEBUG] [backoff.go:220] ["retry later"] [error="region not found for key \"mBootstra\\xffpKey\\x00\\x00\\x00\\x00\\xfb\\x00\\x00\\x00\\x00\\x00\\x00\\x00s\""] [totalSleep=30737] [maxSleep=1200000] [type=pdRPC] [txnStartTS=434396103533658114]
[2022/07/06 14:40:59.120 +08:00] [DEBUG] [config.go:139] [backoff] [base=500] [sleep=1835] [attempts=15]

目前我们的集群都是只有tidb-server。

Min_Chen · 2022 年7 月 6 日 06:52

tikv 都正常吗现在？

realcp1018 · 2022 年7 月 6 日 06:55

感觉是正常的，除了之前执行tikv-ctl扫描时把tikv-0 pod设置为runmode=debug时新扩出来一个store之外，其他的都正常，tikv-0刚才也重启过了，目前pdctl里看到6个store都是Up状态，空间也充足。

Min_Chen · 2022 年7 月 6 日 07:03

尝试关闭 load base split 试一下，对所有 tikv 执行：

curl -X POST "http://ip:status_port/config" -H "accept: application/json" -d '{"split.qps-threshold":"3000"}'

参考：https://docs.pingcap.com/zh/tidb/v5.1/configure-load-base-split#使用方法

realcp1018 · 2022 年7 月 6 日 07:40

按文档如果要关闭是要设置的足够大对吧。
还有就是执行报错了，我在所有tikv试了一遍，一样的错误，只是手动touch什么的是正常的不知道为何会报read only，找了半天搞没明白：
failed to update, error: Os { code: 30, kind: Other, message: “Read-only file system” }
我尝试在tikv pod里执行下

Min_Chen · 2022 年7 月 6 日 07:58

要直连到 tikv 的 IP 啊，建议在 pod 里执行。

realcp1018 · 2022 年7 月 6 日 08:28

还是一样的报错，可以两个一起改吧。
直接curl考进去执行报so缺失。

Min_Chen · 2022 年7 月 6 日 09:02

你的 pv 怎么 provision 的？NFS 吗？文件系统只读？
手动在 tikv 目录下 touch 个文件试试呢。

realcp1018 · 2022 年7 月 6 日 09:05

刚才试过在/var/lib/tikv下touch/rm了一个文件，没有错误
目前pv是由longhorn提供的，我尝试找下原因

realcp1018 · 2022 年7 月 6 日 09:07

16:59左右开始出现tikv-2这个pod 状态变为CrashLoopBackOff的问题。
报错为：

[2022/07/06 17:06:04.659 +08:00] [INFO] [raft.rs:2605] ["switched to configuration"] [config="Configuration { voters: Configuration { incoming: Configuration { voters: {16205840, 16185066, 16185067} }, outgoing: Configuration { voters:{} } }, learners: {27166146}, learners_next: {}, auto_leave: false }"] [raft_id=16185066] [region_id=16185064]
[2022/07/06 17:06:04.747 +08:00] [INFO] [region.rs:387] ["apply new data"] [time_takes=53.550703ms] [region_id=13228245]
[2022/07/06 17:06:04.906 +08:00] [FATAL] [lib.rs:462] ["assertion failed: `(left == right)`\
  left: `27165165`,\
 right: `103435`"] [backtrace="stack backtrace:\
   0: tikv_util::set_panic_hook::{{closure}}\
             at components/tikv_util/src/lib.rs:461\
   1: std::panicking::rust_panic_with_hook\
             at library/std/src/panicking.rs:595\
   2: std::panicking::begin_panic_handler::{{closure}}\
             at library/std/src/panicking.rs:497\
   3: std::sys_common::backtrace::__rust_end_short_backtrace\
             at library/std/src/sys_common/backtrace.rs:141\
   4: rust_begin_unwind\
             at library/std/src/panicking.rs:493\
   5: core::panicking::panic_fmt\
             at library/core/src/panicking.rs:92\
   6: core::panicking::assert_failed_inner\
             at library/core/src/panicking.rs:0\
   7: core::panicking::assert_failed\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/core/src/panicking.rs:117\
   8: raftstore::store::fsm::store::StoreFsmDelegate<EK,ER,T>::check_msg\
             at home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/store.rs:1485\
      raftstore::store::fsm::store::StoreFsmDelegate<EK,ER,T>::on_raft_message\
             at home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/store.rs:1606\
   9: raftstore::store::fsm::store::StoreFsmDelegate<EK,ER,T>::handle_msgs\
             at home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/store.rs:596\
      <raftstore::store::fsm::store::RaftPoller<EK,ER,T> as batch_system::batch::PollHandler<raftstore::store::fsm::peer::PeerFsm<EK,ER>,raftstore::store::fsm::store::StoreFsm<EK>>>::handle_control\
      at home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/store.rs:818\
      batch_system::batch::Poller<N,C,Handler>::poll\
             at home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/components/batch-system/src/batch.rs:300\
  10: batch_system::batch::BatchSystem<N,C>::start_poller::{{closure}}\
             at home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/components/batch-system/src/batch.rs:422\
      std::sys_common::backtrace::__rust_begin_short_backtrace\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/std/src/sys_common/backtrace.rs:125\
  11: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/std/src/thread/mod.rs:474\
      <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/std/src/panic.rs:344\
      std::panicking::try::do_call\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/std/src/panicking.rs:379\
      std::panicking::try\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/std/src/panicking.rs:343\
      std::panic::catch_unwind\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/std/src/panic.rs:431\
      std::thread::Builder::spawn_unchecked::{{closure}}\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/std/src/thread/mod.rs:473\
      core::ops::function::FnOnce::call_once{{vtable.shim}}\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/core/src/ops/function.rs:227\
  12: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once\
        at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/alloc/src/boxed.rs:1546\
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once\
             at rustc/16bf626a31cb5b121d0bca2baa969b4f67eb0dab/library/alloc/src/boxed.rs:1546\
      std::sys::unix::thread::Thread::new::thread_start\
             at library/std/src/sys/unix/thread.rs:71\
  13: <unknown>\
  14: clone\
"] [location=/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/store.rs:1485] [thread_name=raftstore-6-1]

完整log如下：tikv.log (8.5 MB)

pingyu · 2022 年7 月 6 日 13:00

说明至少有部分 meta region 数据还在。显示有 30 个 key 是因为这个命令默认 limit 30。
具体哪些 store 有这个数据，哪些没有？

realcp1018 · 2022 年7 月 6 日 13:55

这个region如果是像其他数据表的region一样也是3副本且遵循pd调度规则的话，那应该是3副本齐全的，因为之前region check已经没有看到缺失副本的region了。
如果这种元数据region是每个store一份的话，至少tikv-0的pod是有的，其他的tikv没有暂停扫描过推测应该都还在。
如果元数据还在我们有处理tidb那个DEBUG报错的方法吗？关于其他tikv pod是否包含meta region，我明天验证下。

Min_Chen · 2022 年7 月 7 日 02:50

这个原因找到了吗？可以执行

curl -X POST "http://ip:status_port/config" -H "accept: application/json" -d '{"split.qps-threshold":"3000"}'

了吗？

region not found for key "mBootstra\xffpKey 还在看有没有方法恢复。

realcp1018 · 2022 年7 月 7 日 03:21

还没，在同一个k8s集群的同一个namespace的另一个运行良好的集群里试了下，也是一样的报错。
这两个集群用的都是同一个storageClass。
然后在一个物理机测试集群试了下，我写的那个简易工具能修改掉 split.qps…的两个参数。推测是k8s环境有此类限制或者longhorn这种storageClass有此类限制。目前我们没有其他存储pv类型可供测试