-- 1. 确认旧 br 进程确实已死（SSH 中断前台进程通常已被 SIGHUP 杀掉，但请核实）
-- ps -ef | grep br
-- 2. 查看任务记录（注意：是 mysql.tidb_global_task，不是 subtask 表）
SELECT id, task_key, type, state, state_update_time, start_time
FROM mysql.tidb_global_task WHERE id = 2122524;
-- 3. 顺手核对同任务是否残留子任务/历史记录
SELECT * FROM mysql.tidb_backgr…
18 天前
官方最佳实践也不推荐扩大版本升级吧
2 个月前
看标题忍不住笑了，不该笑。
tidb不能回退吧。 有备份吗
2 个月前
No tasks yet BR 在 backupmeta 里没找到任何需要恢复的 SST，大概率是备份时表不存在或者 local 存储的文件不完整。
3 个月前
一.SPLIT 的本质：它只是在 _tidb_rowid 的空间上预先画了几个切分点（split points），把 [0, 2^63) 这个区间物理切割成多个 Region。但关键问题在这里：如果写的是单调递增的自增主键（CLUSTERED 表），新写入的 RowID 一个比一个大——它们永远落在最末尾那个Region 的范围内。SPLIT 切分出的前面那些 Region 根本不会收到任何新写入。
二.PD 热调度做了什么
探测热点：通过 TiKV 心跳中的 StoreState（磁盘、读写速率）和 RegionState（Leader 位置、读写速率）检测
热 Region 识别：检…
3 个月前
TiDB 的优化器成本模型中，对回表操作的 网络延迟惩罚（network latency penalty） 非常重。当 TiDB认为回表代价高时，会倾向选择全表扫描 + 并行处理。
3 个月前
TiDB 不喜欢的不是二级索引本身，而是 大批量回表操作。当你的 SQL 经过二级索引筛选后仍需读取大量行时，TiDB 认为直接并行扫全表 + Coprocessor下推过滤效率更高。这是分布式数据库面对大量随机读时的理性选择——用计算换IO
3 个月前
TiDB 底层 TiKV 采用 Multi-Raft 架构，将数据划分为多个 Region，每个 Region 对应一个独立的 Raft Group，实现数据分片与复制；Region 的分裂、合并、迁移及集群负载均衡由 PD（Placement Driver）统一调度。
写入侧，TiKV 基于事件驱动模型处理 Raft Ready，各 Region 的 Raft 日志通过 RocksDB WriteBatch 批量提交落盘，并结合日志复制流水线（Pipeline Replication）、网络消息批处理等机制显著提升写入吞吐。
读取侧提供多种一致性方案：
Raft Log Read：通过…
3 个月前
TiDB 底层 TiKV 依托 Multi-Raft 架构，将数据划分为独立 Region 对应单独 Raft 组完成数据分片，Region 分裂、合并、迁移与集群负载均衡由 PD 调度实现；TiKV 采用事件驱动模型处理 Raft Ready，各 Region 独立使用 RocksDB WriteBatch 批量落盘，搭配日志复制流水线、网络消息批处理提升写入吞吐。读取侧分层提供多种一致性方案：Raft Log Read 为写读合一强一致方案极少使用；ReadIndex 通过一轮多数派心跳确认 Leader 身份规避日志写入开销；Lease Read 依靠心跳持续续期租约，租约时长受选举超时…
3 个月前
没有更多内容了