【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.1
【资源配置】2个Tidb server，3个Tikv server，2个TiFlash server
【遇到的问题】
2个Tidb server，这里我们叫它serv1、serv2；
平时都在使用serv1，serv2并没有放流量进来，仅作为备用节点；
serv1发生异常重启，重启之后统计信息都丢失了，执行 SHOW STATS_HEALTHY 结果为空；
但是 serv2 的统计信息看起来还是正常的，执行 SHOW STATS_HEALTHY 正常显示；
在 serv1 执行
analyze db_name.一个很小的表
，卡了两个小时了，没执行完。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
这个看看
你把所有tidb都停止 再启动
service tidb-4000 stop;
service tidb-4000 stop;
service tidb-4000 stop;
service tidb-4000 start;
service tidb-4000 start;
service tidb-4000 start;
登录到每一台 等全部停完了再启动 是tidb卡住了
prod pd和tikv不要混部，早晚有可能出问题的
这个问题不大
可能serv1异常重启的时候统计信息没有正常加载，这个节点可以的话正常重启一下，重新加载下统计信息
到 tidb-server 的日志里 grep 一下init stats，看下真正加载花了多长时间。6.5.3之前 tidb-server 加载统计信息会特别慢，需要升级到6.5.3之后的版本才会缓解，不过真正解决，是需要7.1的 lite-init-stats + force-init-stats才能彻底解决，tidb-server 启动后有一段时间没有统计信息的隐患。可以参考这个例子，我还遇到过直接加载统计信息失败的情况。
启动就好了
tikv内存用太多了，用命令把占用内存上线调小点，可以立即生效。
至于tidb最好都重启下
意思是tidb发生异常重启的话，要重新手动所有tidb实例么？
#6.5.3之前 tidb-server 加载统计信息会特别慢#
总共1.5T的数据，是不是就要加载两个小时这么久？
报空指针了，所以没有执行到 init stats
[misc.go:116] [“panic in the recoverable goroutine”] [label=domain] [funcInfo=loadStatsWorker] [r=“"invalid memory address or nil pointer dereference"”] [stack=“github.com/pingcap/tidb/util.Recover\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/util/misc.go:120\nruntime.gopanic\n\t/usr/local/go/src/runtime/panic.go:884\ngithub.com/pingcap/tidb/executor.(*ExecStmt).Exec.func1\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/adapter.go:440\nruntime.gopanic\n\t/usr/local/go/src/runtime/panic.go:884\nruntime.panicmem\n\t/usr/local/go/src/runtime/panic.go:260\nruntime.sigpanic\n\t/usr/local/go/src/runtime/signal_unix.go:835\ngithub.com/pingcap/tidb/planner/core.NormalizeFlatPlan\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/planner/core/encode.go:271\ngithub.com/pingcap/tidb/executor.getPlanDigest\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/adapter.go:1651\ngithub.com/pingcap/tidb/executor.(*ExecStmt).observeStmtBeginForTopSQL\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/adapter.go:1840\ngithub.com/pingcap/tidb/executor.(*ExecStmt).Exec\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/adapter.go:505\ngithub.com/pingcap/tidb/session.runStmt\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/session/session.go:2351\ngithub.com/pingcap/tidb/session.(*session).ExecuteStmt\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/session/session.go:2215\ngithub.com/pingcap/tidb/session.(*session).ExecuteInternal\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/session/session.go:1676\ngithub.com/pingcap/tidb/statistics/handle.(*Handle).initTopNCountSum\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/statistics/handle/bootstrap.go:338\ngithub.com/pingcap/tidb/statistics/handle.(*Handle).initStatsHistograms4Chunk\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/statistics/handle/bootstrap.go:144\ngithub.com/pingcap/tidb/statistics/handle.(*Handle).initStatsHistograms\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/statistics/handle/bootstrap.go:185\ngithub.com/pingcap/tidb/statistics/handle.(*Handle).InitStats\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/statistics/handle/bootstrap.go:415\ngithub.com/pingcap/tidb/domain.(*Domain).loadStatsWorker\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/domain/domain.go:1882\ngithub.com/pingcap/tidb/util.(*WaitGroupWrapper).Run.func1\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/util/wait_group_wrapper.go:33”]
不用，只用重启init stats失败的tidb-server就行了。6.5.3之前不管正常重启tidb-server，还是异常重启，都要先grep 'init stats' tidb.log，只有日志里这条记录才代表，统计信息加载成功可以对外提供服务了，如果没有出现就不要让它承接线上流量。
其实和数据量关系倒不是很大，是不是这个集群表特别多？尤其是分区表数量多么？
重新启动下就好了
