AskTUG Weekly (20191118-20191124) DM 最新版本任务如何配置?如何查看 load data 后的详细信息?

问答

Q1:【DM】场景描述:

事务一(插入表 T1,T2):
开始时间:00:00:00
insert into t1(id,name) values(1,'a');
insert into t2(id,name) values(2,'b');
结束时间:00:00:06

事务二(修改 T2):
开始时间:00:00:07
update t2 set name = 'a' where id = 2;
结束时间:00:00:08

问题:

上述场景中,能不能确保事务 2 中的修改语句一定在插入表 T1 数据之前运行?

根据官网描述,只能保证事务 2 中的修改语句一定在插入表 T2 数据之前运行,并不能保证在插入表 T1 数据之前运行?我的理解对吗?

另:如果事务 2 执行的也是 insert 语句,冲突检测时会认定为冲突吗?能保证事务 2 中的插入语句一定在插入表 T2 数据之前运行吗?

查看详情:DM 同步的事务冲突检测与事务执行的顺序性

Q2:【TiDB】背景:

目前 Hive 的元数据库使用的是 MySQL,总行数已经快达到 4 亿,单表数据行数超过 1 亿,而且数据量还在不断增加,Hive Metastore 查询 MySQL 延迟很高,性能达到瓶颈。

问题:

  • 在这种场景下,TiDB 是否合适做 Hive 的元数据存储? 之前有没有这样的使用案例?
  • 我使用 Docker Compose 做了下简单测试,Hive Metastore 连接 TiDB 是没有问题的,建立库也是 OK 的,但是建表的时候发生这样的错误:
java
2019-11-18T10:47:15,520 ERROR [pool-9-thread-4] thrift.ProcessFunction: Internal error processing lock
org.apache.hadoop.hive.metastore.api.MetaException: Unable to update transaction database com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use line 1 column 9 near "SAVEPOINT `__7f378d91_16e7c5aa880__7ffa`"

查看详情:Hive Metastore 元数据库如何使用 TiDB

Q3:【TiDB】TiDB 同步数据到 Kafka 后,通过 Streaming Structured 接受数据报错。每次清空 Kafka的 Checkpoint 后就好了,应该是数据堆积太多。但是我调整 Kafka 参数、调整 Streaming Structured 接收端均无用,是否跟 TiSpark 或者 Binlog 有关?出现场景通常为 Spark 应用长时间未开启后重启、或重新同步 TiDB 表时 Load 发生。

具体信息如下:

org.apache.kafka.common.errors.RecordTooLargeException: There are some messages at [Partition=Offset]: {kafka_obinlog-0=621412} whose size is larger than the fetch size 1048576 and hence cannot be ever returned. Increase the fetch size on the client (using max.partition.fetch.bytes), or decrease the maximum message size the broker will allow (using message.max.bytes).

查看详情:TiDB 同步数据到 Kafka 后,通过 Streaming Structured 接受数据报错 messages larger than fetch size

Q4:【TiSpark】TiSpark 分批次读取 TiKV,多个批次后报错 send tikv request error: UNAVAILABLE, try next peer later,TiKV 日志报错 peer is not leader,请问是什么原因呢?查看详情:TiSpark分批次读取 TiKV,多个批次后报错 send tikv request error: UNAVAILABLE, try next peer later

Q5:【TiDB】TiDB 集群 Mydumper 备份完后,用 Loader 导入数据报错:Column count doesn’t match value count at row 1,问题看着像是用 Mydumper 备份的时候,加上 -r 参数,会把 SQL 截断,

备份命令:

/mydumper -h "xxxxxxx" -P "xxxxxx" -u "xxxxx" -p "xxxxxx" -t 16 -F 64 --skip-tz-utc -r 100000 --logfile mydumper.log -o ./data/

导入命令:./loader -h xxxx -u xxxx -P xxxx -t 32 -d ./data/

报错:

[warning] [exec][sql][USE `xxxx`; INSERT INTO `xxxxx` VALUES(xx,xx,'xx',xx,xx,xx,xx,xx UPDATE `tidb_loader`.`checkpoint` SET `offset`=xx WHERE `id` ='xx' AND `filename`='xx.s][error]Error 1136: Column count doesn't match value count at row 1

请问是什么原因呢?查看详情:Mydumper+Loader迁移集群报错:Column count doesn’t match value count at row 1

Q6:【TiDB】生产环境使用 TiDB 已经 5 个月了, 之前使用的版本是 2.1.6,现已升级到 3.0.2。在此期间出现了一些问题:升级到 3.0.2 后,TiKV 的 CPU 使用率增加了 80%,现在出现了一些严重的性能问题, TiDB 集群在删除数据、删除表时变得很慢,查询性能也慢了,目前我查不到性能瓶颈在哪里,请问该如何排查问题?查看详情:TiDB 使用一段时间出现的一些问题

Q7:【DM】DM 集群最新版本已经安装成功,也能够正常启动 DM 集群,但是在 dm_master 和dm-worker 的 conf 下并没有 task.yaml.example 文件,也没有看到 task_basic.yaml 和 task_advanced.yaml 文件。想问下最近版本的 DM 启动数据迁移任务,到底是使用哪一个文件,文件位于哪个目录下面,master 和 worker 都需要配置吗?查看详情:DM 最新版本任务配置问题

Q8:【TiDB】请问:如何打开或配置 TiDB 的审计日志

Q9:【TiDB】目前 3 PD 独立机器,3 tidb-server、3 TiKV 共同部署 3 SSD 机器,考虑 Dump 部署在普通机器上面,不知道是否会影响 TiDB 集群整体的读写性能;目前计划 Drainer 同步到 MySQL,而 MySQL 对于同步延迟本身没有太高的要求。查看详情:Dump 的机器性能差是否会影响 TiDB 的性能

Q10:【TiDB】在使用 load data 导入数据后,会有结果提示 skip 了多少行 ,有多少 warnings。 使用show warnings 进一步查看信息,信息提示只给出了 truncate data 的信息,但并没有告诉我是哪一行的哪一个字段 truncate data。而 MySQL 是可以查看到具体哪行哪个字段被截断的。

请问应该如何查看当次 load data 后,有哪些行被 skip 了,warnings 信息里的具体哪一行哪一个字段出现警告了?查看详情:怎么查看 load data 后的详细信息

活动

继 10 月 TUG 在沪、京、深、蓉四城联动举办线下技术沙龙后,11 月 TUG 又迎来了三城联动。除了北京、华南 TUG 外, 杭州 TUG 也开启了线下技术沙龙,与新伙伴们见面。

  • 北京活动主题:高可用架构设计与实践
  • 华南活动主题:TiDB 性能调优专场
  • 杭州活动主题:双十一/黑五等高并发场景下的技术架构与实践

文章

九月 TUG 线下活动中,58 集团 DBA 旋凯分享了 58 集团的 TiDB 实践及使用经验,主要介绍了 TiDB 在 58 集团的使用业务和概况,TiDB 的选型过程以及 58 集团的 TiDB 体系建设。

在 TiDB 的使用过程中,调优是大家都关注的话题。58 集团 DBA 刘春雷给大家分享了两次 TiDB 优化的过程,详细介绍了步骤和优化前后的数据对比。

  • 记一次 TiDB 优化:TiDB 订单业务集群优化,通过 TiKV 参数调优,开启静默 region 和 region merge,最后大大优化了 SQL 执行时间,降低整体 CPU 容量并提升 IO 性能。
  • 再记一次业务优化:安居客 TiDB 集群优化过程,通过替换机器,调整 TiKV 实例数,进行表优化和慢 SQL 优化等步骤,有效降低了 SQL 执行时间和 region 数量。

更多阅读:

AskTUG Weekly (20191111-20191118) 动态表单的场景 TiDB 是否适用?TiDB 对清除数据有没有最佳实践?