-我手动删除了断点文件，还是报同样的错。

这文档上也没提，哈哈。那怎么手动清理啊。

同样的错误，校验值不一样。 我用tidb-lightning-ctl --checkpoint-error-destroy=all，再重启lighting，还是一样的错误。

tidb-lightning-ctl --checkpoint-error-destroy=all 这个是清除断点的操作么

这张表可能本身已有数据，影响最终结果。 如果目标数据库的校验和全是 0，表示没有发生任何导入，有可能是集群太忙无法接收任何数据。 如果数据源是由机器生成而不是从 Mydumper 备份的，需确保数据符合表的限制，例如： 自增 (AUTO_INCREMENT) 的列需要为正数，不能为 0。 唯一键和主键 (UNIQUE and PRIMARY KEYs) 不能有重复的值。 如果 TiDB Lightning 之前失败停机过，但没有正确重启，可能会因为数据不同步而出现校验和不一致。 按官方文档，我排除了1,2,3点原因的可能性。

机器有45G,内存,执行过程中一直用free -g监控内存,结果它全用完了,然后就OOM了.

Jun 9 09:00:03 2020] VM Periodic Tas invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [Tue Jun 9 09:00:03 2020] [] oom_kill_process+0x254/0x3d0 [Tue Jun 9 09:00:03 2020] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name [Tue Jun 9 09:00:03 2020] haproxy inv…

报错了,麻烦看看具体是啥原因

[tidb@tidb1 ~]$ tiup bench tpch --sf=10 --db tpch_10 --host 172.16.8.36 run -p kaifa#pm Starting component bench: /home/tidb/.tiup/components/bench/v0.0.2/bench tpch --sf=10 --db tpch_10 --host 172.16.8.36 run -p kaifa#pm [CUR] Q1 - Takes(s): 8.9, Count: 1, TPM: 6.7, Sum(ms): 41076, Avg(ms): 410…

[CUR] Q22 - Takes(s): 0.6, Count: 1, TPM: 101.7, Sum(ms): 990, Avg(ms): 990, 95th(ms): 1000, 99th(ms): 1000, 99.9th(ms): 1000 请问上述 COUNT,TPM, CUR/SUM的含义是?

按文档准备后,手动执行SQL么?

发现了一个文档上的错误, 这个下推计算的参数是会话级别的. set global tidb_opt_distinct_agg_push_down = 1; SQL 错误 [1105] [HY000]: Variable ‘tidb_opt_distinct_agg_push_down’ is a SESSION variable and can’t be used with SET GLOBAL

恩，使用外部服务器。

恩，我猜测也是，手动同步下时间之后的就好了。tiup部署有参数可以调整ntp的服务器么，我想换成亚洲的服务器。

pd-ERROR.log (395.8 KB)

[2020-05-09%2017-27-43%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE] [2020-05-09%2017-25-51%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE] meta.yaml (3.2 KB)

scale-out.yaml的缩进没搞好。现在已经部署好了。

[%E9%80%89%E5%8C%BA_012] [%E9%80%89%E5%8C%BA_009] dashboard有些谬误