正常来说这个指标是进程启动的时间戳,没有重启是不会变化的,也就不会告警,不要看这个 changes 表达式了,把 changes 函数去掉看下
就算换 3.5 T 盘,数据也不要太多,因为你计算资源不够啊,就 16C,现在 cpu 都已经 40% 了,那数据要变为原来 2 倍,岂不是 cpu 都 80% 了
都行,如果硬件故障修的时间比较短,比如 1 天就修完了,可以直接停下来修,修好了再起来就行了
风险就是在你修的这 1 天里,再坏一台机器就无法正常对外提供服务了
【大家学习 TiDB 课程的进度如何?看过哪些课程,体验如何?】
就看过 PCPT 的课程,讲的很细
【你希望未来 TIDB 社区举办哪些主题的 TiDB 学习活动呢?你最期待的活动形式和学习内容是?】
来一个每天一道的题吧,类似墨天轮,答对还可以给一点积分
【需求描述】您当前是否有使用空间类型函数的业务需求?若目前没有,未来有计划在业务中使用吗?
有使用过,之前一个运营商的资源管理系统,设备相关空间信息用到过,会在地图上标记一些设置位置,并且一些业务逻辑中也会用到
【场景描述】您当前业务中的哪些场景会需要使用空间类型函数?希望具体支持哪些业务,或者解决哪些痛点问题?
当前业务没有用到空间类型函数
数据库是这种软件对数据一致性要求很高的,虚拟化层可能有些设置会导致 IO 没有落盘,当崩溃时写入丢失,从而导致数据不一致
看问题时的执行计划,数据量有可能有变化,执行计划也有可能有变化
怎么看出来无法正常运行的,你可以看看是否有调度产生啊
官方不建议跑在 docker 上吧,跑 docker 上都是临时测试下,生产上边怎么维护啊,不行上 k8s 也行啊
前边说了,找个空闲实例,或者别用分区表,还就就是降低扫描并发度吧
看报错是什么表,去 dashboard 里日志搜索搜 command dispatched failed 关键字,可能是分区表
超过了集群内存参数限制,降低并发,或者在一个空闲的 tidb 实例上搞吧
没必要,TiDB 数据库整个设计都是为分布式数据库设计,不是你直接单副本就能好用,想单副本,就直接选单机吧
那你自己部署一个 prometheus 服务不就好了