AskTUG Weekly (20190923-20190930)

问答

Q1:【Loader】按照 TiDB 官方 Ansible 部署,因为测试环境跳过了系统检测,所有参数都是默认配置 然后从开发环境导出数据 导出语句 ./bin/mydumper -h 172.18.8.30 -P 3400 -u xxx -p ‘xxx’ -t 16 -F 64 -B xxx --skip-tz-utc -o /DATA1/xxx

然后使用 Loader 导入 /DATA1/tools/tidb-tools/tidb-enterprise-tools-latest-linux-amd64/bin/loader -d /DATA1/xxx/ -h 127.0.0.1 -u root -P 4000

问题: 再倒入部分数据后,报错 2019/09/23 18:04:31 loader.go:124: [fatal] Error 1062: Duplicate entry ‘18855454’ for key ‘PRIMARY’

重试 删除tidb-loader库和已经导入数据的库后还是会有相同问题 有时候重试还会有2019/09/23 16:39:39 loader.go:190: [error] init sale_vip.t_collect_honey.000000010.sql checkpoint error:initialize checkpoint: invalid connection这种报错

查看表的批量sql文件,确认只有这一个主键值并且在数据库中已经插入。查看详情:Loader 导入时主键冲突

Q2:【查询】PD 3 台, TiDB 2 台,TiKV 3 台, 磁盘型号:SAS。执行 SELECT ac,dtime,ranges from data_detail where mmc in (‘1422’,‘1fdf’,‘14de’,‘ed1b’,‘ecd9’,‘6292’,‘ecef’) , Select 2千万行数据查询时间需要30s以上

Q3:【Pump】添加 Pump 节点一直停留在 wait until the pump port is up,无法启动,是什么情况,之前有添加过 Pump 和 Drainer 节点,因磁盘故障无法使用。是否需要先下线 Pump 节点和 Drainer 节点,如何下线?查看详情:添加 Pump 节点一直停留在 wait until the pump port is up,无法启动

Q4:【TiDB】上游 MySQL 实例中,有一个 Account 库,这个库里面有 3 个表,各拆分了 50 张表,想把 3 个类型的分表,再分别合并到 TiDB 中 3 个表中。发现合完的表,数据对不上:

image

查看详情:MySQL 到 TiDB 数据迁移问题

Q5:【TiDB】当有人运行导出大数据量的操作时,会出现 TiDB 节点连接超时。 通过观察系统状态,发现网卡流量在 1G,一旦通过 SQL 造成流量到达 1G,连接就会超时。但是网卡总流量能达到 2G,通过 SCP 文件测试出的结果。请问 TiDB 集群中是否有参数限制?查看详情:TiDB 节点连接超时

Q6:【Syncer】使用 Syncer 同步时报错,gen update sqls failed: update columns and data mismatch in length: 16 vs 15 查看上下游表结构,数量一致,没有使用 RDS 特性的那个隐藏主键问题。查看详情:Syncer 同步报错:Columns Length 不一致

Q7:【DM】我们建了一张没有主键的表,有 40 个 Columns。使用 DM dump 出历史数据能导入进去,但是在使用 DM 同步增量数据的时候报错:


"msg": "[code=36027:class=sync-unit:scope=internal:level=high]

gen insert sqls failed, schema: lejiapay, table: tc_**_report: Column count doesn't match value count: 40 (columns) vs 41 (values)

\ngithub.com/pingcap/dm/pkg/terror.(*Error).Generate\n\t/home/jenkins/workspace/build_dm_master/go/src/github.com/pingcap/dm/pkg/terror/terror.go:232\ngithub.com/pingcap/dm/syncer.genInsertSQLs\n\t/home/jenkins/workspace/build_dm_master/go/src/github.com/pingcap/dm/syncer/dml.go:120\ngithub.com/pingcap/dm/syncer.(*Syncer).handleRowsEvent\n\t/home/jenkins/workspace/build_dm_master/go/src/github.com/pingcap/dm/syncer/syncer.go:1462\ngithub.com/pingcap/dm/syncer.(*Syncer).Run\n\t/home/jenkins/workspace/build_dm_master/go/src/github.com/pingcap/dm/syncer/syncer.go:1269\ngithub.com/pingcap/dm/syncer.(*Syncer).Process\n\t/home/jenkins/workspace/build_dm_master/go/src/github.com/pingcap/dm/syncer/syncer.go:578\ngithub.com/pingcap/dm/syncer.(*Syncer).Resume\n\t/home/jenkins/workspace/build_dm_master/go/src/github.com/pingcap/dm/syncer/syncer.go:2250\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337"

查看详情:DM 增量数据同步报错

Q8:【DM】线上有 4 张表:

  1. asset_fund_1_201901
  2. asset_fund_2_201903
  3. asset_fund_month_1
  4. asset_fund_month_10

匹配以 asset_fund_ 开头,后面是数字且带下划线的 table 1 和 2,使用正则: asset_fund_[0-9]+_[0-9]+

发现不生效。很奇怪这么简单的正则,为啥 DM 识别不了?查看详情:请教一个匹配分库分表的 table-pattern,是否有 bug

Q9:【TiKV】现在告警 TiKV async request write duration seconds more than 1s 这个值越来越大。按 wikihttps://pingcap.com/docs-cn/v3.0/reference/alert-rules/#tikv_channel_full_total 讲解,是 TiKV 压力过大导致。能否定位到具体的 SQL 导致 KV 压力过大?到具体的告警的KV 节点,查看 KV 日志,搜寻 slow_query 关键字,定位相关时间的 table_id 查看所有 TiDB 的 slow_log 感觉并不符合预期,只有1-2 条的简单查询。麻烦问一下有没有更详细的关于这个告警的处理方法?查看详情:关于 TiKV async request write duration seconds more than 1s 告警应该如何查看具体的 SQL 导致 KV 压力过大?

Q10:【DM】DM 执行任务的时候,只做了 Dump,没有进行 Loader,直接 Syner 了

  • 查看了 Work 的文件目录,看到 dump 的 SQL 已经存在
  • 上游是阿里云的 RDS
  • 查看 TiDB 的数据库中,数据库创建了,但是数据库中没有表。

请问是什么原因呢?查看详情:DM 执行任务的时候,只做了 Dump,没有进行 Loader,直接 Syner了

文章

Spark Standalone 集群升级步骤 介绍了 Spark Standalone 集群部署原理,集群配置文件,集群运维和集群升级步骤。

sql-skip 有两种跳过错误的方式: 1.使用日志 position 方式跳过; 2.使用 SQL 语句方式跳过。 详情示例查看:DM 的 dmctl 中 sql-skip 使用


相关阅读:

AskTUG Weekly (20190916-20190922)