jiyf
jiyf
V8
2020-10-29 加入
获赞
67
回答
69
文章
17
    你这里是用的 dumpling 4.X 版本备份的 tidb 吗?翻了下这部分代码,它会根据平均单行数据大小,设置个这个参数,所以那个 400649 应该是 dumpling 优化自己计算的。 af func (d *Dumper) buildConcatTask(tctx *tcontext.Context, conn *sql.Conn, meta TableMeta) (*TaskTableData, error) { tableChan := make(chan Task, 128) errCh := make(chan error, 1) go func() { //…
    5 天前
    count := estimateCount(dbName, tableName, db, field, conf) log.Info("get estimated rows count", zap.Uint64("estimateCount", count)) if count < conf.Rows { // skip chunk logic if estimates are low log.Debug("skip concurrent dump due to estimate count < rows", zap.Uint64("estimate count", c…
    5 天前
    意思就是你在备份的时候设置了 -r 参数为 400649,dumpling 会根据这个参数并发导数据。 但是由于对要备份的表行数进行估计,只有 47383 行,所以 dumpling 就不采用并发方式了,直接整个表一个 select 查询导出来。 这个 WARN 直接忽略就行,没有影响。如果都是小表,行数都比较少,直接把这个参数去掉;或者就是把 -r 参数设置的更小,目前的设置值 400649,其实挺大的,也是导致对一个表不能使用并发导出的原因。
    5 天前
    正常的,首先说就是符合常理。 haproxy 的 check 是探活,也就是检查后端的服务是否正常,基于 tcp 探活会尝试连接后端 tidb 的 4000 端口。 tidb server 跟 check 建立连接后会等待收消息,但是 check 建立连接成功就说明后端在线,然后关闭连接,这时候 tidb server 因为 check 的连接意外断开打印报错日志。 check 是定时的,所以不会有太多,影响不大,主要的影响是打印了太多 ERROR 日志,干扰排查问题。 tidb 集群 prometheus 探活 tidb 是用的 10080 端口,不是探活的 4000 端口,所以没…
    5 天前
    mysql> explain analyze select * from CLUSTER_SLOW_QUERY order by Time desc limit 1; +----------------------------+---------+---------+-----------+--------------------------+-------------------------------------------------------------------------------------------------------------------------------…
    5 天前
    单行记录,根据表结构定义以及索引数能确认会编码多少个 kv entry: 假设表中有 N 个索引(包括主键),如果是聚簇表,那么 kv entry 个数是 N; 如果是非聚簇表,kv entry 个数是 N + 1,相对于聚簇表,会多一个。 具体的编码规则可以参考《三篇文章了解 TiDB 技术内幕 - 说计算》 https://pingcap.com/zh/blog/tidb-internal-2 具体的 entry 大小,跟数据有关。 linghtning local 模式在导入数据前会把把数据编码为 kv entry,有兴趣可以观察下。
    1 个月前
    是不是三个概念搞混了: Lease Read 是 raft leader 用来确认其仍然是 leader 的租约,在 lease 租约内,不允许其他 voter 选主成功,leader 通过租约时间确认其 leader 地位(不用通过发送心跳确认)。 Follower Read 指的是从 follower 节点读,follower 是 raft 一个角色。 ReadIndex Read 是在 Follower Read(从 follower 或者 learner 节点读取)情况下,保证一致性读的方法,就是在 follower 或者 learner 节点读取的时候,向 leader 确认下当…
    1 个月前
    你这里 dumpling 参数用了 -r 200w,也就是说一个文件保存 200w 条以内的记录。 当 dumpling 设置 -r 参数时候,dumpling 会通过 int类型的主键或者唯一索引来预估数据范围,通过并发读取加快导出数据速度。 看 dumpling 报错日志为 WHERE id >=221924767 and id <225506177,这个时候导致了问题,应该就是预估这个范围有 200w 条记录,导致 copr 实际记录过多导致出现问题。 所以你可以试下将 -r 参数调小,减少 where id 的范围,是的 copr 达不到 4G: dumpling -r …
    1 个月前
    按道理讲,是不会不一致的,promSQL一致,数据源一致,所以数据一样才对,你在两个页面同时刷新下看看。
    1 个月前
    你这里提到的方案应该是: dumpling 导出全量数据,这里 dumpling 会有个 metadata 文件,代表导出数据的 pos. 使用 lightning 全量导入 1 步中的数据,采用 local 方式 linghtning 可以完成校验,保证数据一致 dm 开始增量同步,增量同步的开始位置就是 1 步中的 metadata pos,这里 dm 的 checkpoint 会保证一致性 如果在以上哪个环节造成不一致,那就报 bug 吧。 官方 sync-diff 工具也可以进行上下游数据校验。
    1 个月前
    获取 tso 有以下的流程: 构建 tso request,这里有个构建时间 req.start 然后将 request 放进 rpc stream,等待异步执行,这时候有个等待异步执行开始的时间 start := time.Now() 执行结束后计算两个 time: wait 为: now.Sub(start).Seconds() tso 为: now.Sub(req.start).Seconds() 所以可以理解为:wait 是等待异步执行的耗时 tso 是请构建请求到收到 tso 的时间 真正执行 tso rpc 耗时是监控面板中,pd tso rpc duration,…
    1 个月前
    是通过sql写入的,tidb server 执行 sql 就是编码为 kv 键值对,然后写进 tikv,所以这里说 tidb server 进行编码为 kv。
    1 个月前
    我试了下仍然可以。 你是不是检查错数据库了?命令没问题,仔细检查下问题在哪里。
    1 个月前
    tiup dumpling -h “” -P 4000 -p “” -f information_schema.cluster_slow_query -r 10000000 试了下,也可以啊
    1 个月前
    cluster_slow_query 是所有 tidb server 上的慢日志,所以在每个 tidb server 上查都一样。 SLOW_QUERY,只有当前 server 上的慢日志。
    1 个月前
    tiup dumpling -h “” -P 4000 -p “” -T “information_schema.CLUSTER_SLOW_QUERY” -r 10000000
    1 个月前
    我测试了下是可以的
    1 个月前