AskTUG Weekly (20190916-20190922)

问答

Q1:【TiDB】系统版本 CentOS 7.6, TiDB 版本 V3.0.3,Leader Balance Ratio 和 Region Balance Ratio一直是100%,但分别看都是正常的,是什么原因呢?

image

详情查看:Leader Balance Ratio 和 Region Balance Ratio一直是100%

Q2:【TiDB】4 TiKV +3 PD + 3 TiDB, 分别在7台服务器上,目前由于服务器网络变化,需要更新节点的IP,请问该如何操作?详情查看:节点IP变化后,如何操作更新?

Q3:【TiKV】tidb-ansible 集群部署工具是以前在 VMware上部署过的,然后用 TiDB 用户直接拷贝过来使用。 在私有云上部署 TiDB 服务,预检测和部署都 OK,但是启动集群的时候在启动 TiKV 时报错如下:


p=23091 u=tidb | [10.0.1.33]: Ansible FAILED! => playbook: start.yml; TASK: wait until the TiKV port is up; message: {“changed”: false, “elapsed”: 300, “msg”: “the TiKV port 20160 is not up”}

p=23091 u=tidb | [10.0.1.34]: Ansible FAILED! => playbook: start.yml; TASK: wait until the TiKV port is up; message: {“changed”: false, “elapsed”: 300, “msg”: “the TiKV port 20160 is not up”}

p=23091 u=tidb | [10.0.1.35]: Ansible FAILED! => playbook: start.yml; TASK: wait until the TiKV port is up; message: {“changed”: false, “elapsed”: 301, “msg”: “the TiKV port 20160 is not up”}

详情查看:安装部署,tid-ansible-3.0.0 部署后,所有 TiKV 节点都不能启动

Q4:【存储】现在 EXT4 不支持 16TB 以上的容量,TiDB 是否必须 EXT4?如果我这边磁盘超过了 16TB,是不是必须重新把磁盘容量缩容到 16TB 以下并格式化为 EXT4?查看详情:磁盘分区是否必须EXT4

Q5:【DM】上游一些DDL语句,TiDB不兼容,所以需要手动改表,不影响上游的DML 的重放。使用DM,遇到这种手动改造的表,就会发现:table structure compatibility check ,状态fail。如何跳过这项检测?类似这样:ignore-checking-items: [“dump_privilege”, “replication_privilege”] 查看详情:DM 任务如何跳过 table structure compatibility check ?

Q6:【TiKV】系统版本 CentOS 7.6, TiDB 版本 V3.0.3,Grafana TiKV 面板中 Leader 和 Region 一直没有数据,其它指标有数据。

查看详情:Grafana TiKV 面板中 Leader 和 Region 没有数据

Q7:【Binlog】现准备通过采集 TiDB 的 Binlog 到 Kafka,请问有推荐的免费工具吗?详情查看:TiDB 社区版本支持 BinLog 吗?同步到 Kafka 的工具是收费的么?

Q8:【Region】通过如下命令:

./pd-ctl region topwrite 3


{

"count": 3,

"regions": [

{

"id": 1849,

"start_key": "7480000000000001FFA900000000000000F8",

"end_key": "7480000000000001FFAB00000000000000F8",

"epoch": {

"conf_ver": 5,

"version": 199

},

"peers": [

{

"id": 1850,

"store_id": 1

},

{

"id": 1851,

"store_id": 4

},

{

"id": 1852,

"store_id": 7

}

],

"leader": {

"id": 1850,

"store_id": 1

},

"written_bytes": 2990537,

"approximate_size": 48,

"approximate_keys": 387860

},

{

"id": 8993,

"start_key": "7480000000000000FF1700000000000000F8",

"end_key": "7480000000000000FF175F728000000000FF04148E0000000000FA",

"epoch": {

"conf_ver": 5,

"version": 13

},

"peers": [

{

"id": 8994,

"store_id": 1

},

{

"id": 8995,

"store_id": 4

},

{

"id": 8996,

"store_id": 7

}

],

"leader": {

"id": 8994,

"store_id": 1

},

"written_bytes": 2727409,

"read_bytes": 7426114,

"approximate_size": 134,

"approximate_keys": 1314819

},

{

"id": 1045,

"start_key": "7480000000000000FF4100000000000000F8",

"end_key": "7480000000000000FF4300000000000000F8",

"epoch": {

"conf_ver": 5,

"version": 32

},

"peers": [

{

"id": 1046,

"store_id": 1

},

{

"id": 1047,

"store_id": 4

},

{

"id": 1048,

"store_id": 7

}

],

"leader": {

"id": 1047,

"store_id": 4

},

"written_bytes": 1458828,

"read_bytes": 99,

"approximate_size": 12,

"approximate_keys": 91822

}

]

}

我们选第一个 Region 来看,第一行时"id": 1849,,此表示该 Region 的 ID 吧?

可是后面的 Peers 里面有三个副本,分别有三个 ID,且都不与上面的 ID 相同。

Peers 里面的 ID 是什么 ID?(注:最大副本数为3)查看详情:Region ID 和 Peer ID 啥区别

Q9:【TiDB】tidb.log日志中不断打印如下内容,请问如何处理?是否可以通过什么配置关闭?


[2019/09/17 16:31:31.640 +08:00] [INFO] [set.go:190] [“set session var”] [conn=32] [name=autocommit] [val=0] [2019/09/17 16:31:31.720 +08:00] [INFO] [set.go:190] [“set session var”] [conn=32] [name=autocommit] [val=1] [2019/09/17 16:31:31.722 +08:00] [INFO] [set.go:190] [“set session var”] [conn=32] [name=autocommit] [val=0] [2019/09/17 16:31:31.730 +08:00] [INFO] [set.go:190] [“set session var”] [conn=32] [name=autocommit] [val=1]

查看详情:日志内容过大,如何处理?

Q10:【Binlog】在安装部署使用的时候,遇到一些问题,有些是发现一些使用中不方便或者模棱两可的地方,有些是需要了解原理以便更放心的使用,在官网介绍中没有找到明确答案,于是整理出了一些问题:关于 TiDB Binlog 使用中 Pump 和 Drainer 使用方式的问题

活动

9 月 17 日,华南 TUG 迎来了第二次线下活动。这次 TUG 来到了广州的网易互娱,和网易互娱的同学交流 TiDB HTAP 相关的场景和实践。活动中,

  1. 网易互娱高级数据库管理工程师李文杰分享了 “TiDB 在网易互娱的选择与体验”;
  2. 网易互娱的资深运维工程师赵宗飞分享了“传统大数据平台结合 TiDB 的妙用”;
  3. 来自 PingCAP 的分析型产品负责人马晓宇介绍了 TiDB HTAP 的由来,现状及规划

查看详情:华南 TUG 第二次线下活动 “走进网易互娱” 活动回顾

文章

  1. 8月份 TUG 上海区首次线下活动中,UCloud 资深研发工程师常彦德和大家分享了 TiDB 在 UCloud 公有云上的实践。分享内容包括:
  • UCloud TiDB Service;
  • 为了将 TiDB 服务运行在公有云上做了哪些工作;
  • UCloud 为了帮已有用户将业务无缝迁移到 TiDB 上面所做的另外一个产品及扩展;
  • 在使用 TiDB 的过程中遇到的问题及解决方法。
  1. TiDB可以解决数据库的存储瓶颈,但是读写上容易出现热点问题。作者从使用者的角度分享了,处理TiDB 热点相关问题的一些思考和手段。查看原文:TiDB 常见问题处理 - 热点

  2. 360 商业化广告主关键词实时统计报表业务的流程是:业务数据入 Kafka,每 30 秒会有程序读 Kafka 数据进行聚合存储到 TiDB 中,每批次会有几十万的写入,单表数据量1.2~1.5亿。TiDB 在 360 商业化的应用和实践

  3. PingCAP 研发同学上周整理了 DM 错误含义 1 文档。 其中梳理讲解了 DM 现在的基本错误信息含义、错误码列表以及排查方法等。大家后续遇到 DM 的报错可以参考 DM 错误含义和诊断文档整理


AskTUG Weekly (20190909-20190915)

1赞

:+1: