0
0
0
0
专栏/.../

不定期更新,记录一些小知识

 东北大胖子  发表于  2021-02-20

不定期更新,记录一些小知识,欢迎指正,本帖尽量使用文字描述,相关图片尽量粘贴,方便大家搜索~

Mysql向TiDB迁移的方案讨论 数据迁移和数据同步

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。 【TiDB 版本】: v3.0.7, dm-v1.0.2 【问题描述】: 我有一个这样的迁移规划,但最后一部分不知道是否可行,希望能给我一点建议和帮助。 打开DM全量+增量同步数据到TiDB 线上读流量切换到TiDB,进行观察 没有问题后写流量切换到TiDB,同时关闭DM。 第三步中可能部分服务在写Mysql通…

答: DM + 完全业务双写 该方案是在应用端实现双写,并且在指定时间窗口上线双写功能,运行稳定后,可评估写流量切换到 TiDB。

1)使用 DM 完成业务数据的全量和增量同步

2)寻找时间窗口将线上以及 DM 的流量同时切断,并确认数据是否完全同步

3)应用程序端上线双写功能

4)DM 不再作为增量同步的介质,评估后可计划下线

5)应用端正常写入数据到 MySQL 以及 TiDB

6)评估后,写流量切换至 TiDB

tikv log 日志保存数量限制怎么限制 TiDB 系统架构与原理

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。 【TiDB 版本】:v3.0.8 【问题描述】:tikv 服务所在服务器的tikv log 一直增加,旧日志并未减少

答:

如果使用 tidb-ansible 部署,默认编辑 conf/tikv.yml 模板文件,修改相关的参数并执行滚动重启生效就可以了,包括 info-log-max-size、 info-log-roll-time 和 info-log-keep-log-file-num info-log-keep-log-file-num:这个参数是 rocksdb 的日志保留策略,tikv 日志目前还没有相关的参数,需要定期清理一下

rocksdb 的日志位于 {deploy_dir}/data 下的 raft 和 db 目录下,文件名为 LOG 和 LOG.old.xxx; tikv 的日志目前有 log-rotation-timespan,默认 24h 切换一次,对于历史日志需要通过定时任务清理下。

上游mysql ddl,dm同步延迟近7个小时 数据迁移和数据同步

@qizheng-PingCAP谢谢周末一直在支持+1 此问题已经解决,问题是在配置task配置文件时没有加 online-ddl-scheme: “pt” 这个过滤条件,导致最终上游mysql大表ddl操作卡住。 文件添加位置: [image] 因为我这是中途加入这个参数,所以已经有部分操作不可逆了,只能选择跳过卡住的binlog位点。 在跳过binlog这个操作上使用 sql-ski…

答:

DM 增量同步到 TiDB 太慢了

online-ddl-scheme: ‘pt’

这里面正常上游执行 pt-osc ,dm 会跳过相关的拷贝表操作,但是不设置这个参数,dm 还会处理

上游几千万的表执行这个操作,产生了大量的 binlog 需要消费

但是 rename 那里会报错,需要处理下,因为 tidb 不支持一个语句同时 rename 两个

关于TIKV 缩容下线的一些细节疑问 数据迁移和数据同步

知道了,我选监控的时间段选择了,最近一小时,所以显示了,老的数据。 但是。 [image] 在 tidb-cluster-pd 视图中,下线成功,还显示 3个 ,Tombstone 这个地方的显示是正常的吗?

答:

这个存在 PD 的 etcd 里面的数据,如果没有人为干预,这个是一直存在的。

3.0.5 使用 pd-ctl stores remove-tombstone 清理

从3.0.8滚动升级至3.0.10,发现empty-regin-count 突然增加很多,什么原因?有没有办法Merge? TiDB 系统架构与原理

看文档上说的是 “如果 TiKV 不与 TiDB 集群配合运行,建议配置为 ‘default’” 这个怎么理解? 我们现在是 TIKV和TiDB都在使用的,如果配置为’default‘,有没有什么影响? 需要同时设置split-region-on-table: false吗? 我的目的是合并空Region,合并完以后,是否可以把 ‘namespace-classfier’ 改回到 …

答:

空 region

merge 默认情况下表之间是不会相互 merge 的,如果要开启,更改 PD 配置文件,加上 namespace-classifier = “default” (默认是 table), 注:这个参数不能通过 pd-ctl 动态更改。

同时,需要将 tikv 的按 table 分裂配置关闭:

[coprocessor]

split-region-on-table = false

操作:

  1. PD 参数 namespace-classifier = “default”
  2. TiKV 参数 split-region-on-table: false
  3. pd-ctl -i -u http://172.16.5.83:62479 config set max-merge-region-size 16 M config set max-merge-region-keys 50000
  4. ansible-playbook rolling_update.yml -t=pd,tikv

mydumper runs with error: fork/exec bin/mydumper: argument list too long 数据迁移和数据同步

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。 【TiDB 版本】:3.0 【问题描述】:使用dm迁移数据时,在dump数据时出错。问题原因可能是上游mysql数据中有3700多张表,在dm启动task时,自动生成table-list的参数太长了。 是否有什么方式可以通过指定正则表达式的方式来状态这个参数? 若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务…

答:

如果自动生成的 table-list 参数太长。

你可以为 mydumper 在 extra-args 手动用原始的 -x 来指定正则试试([https://pingcap.com/docs-cn/stable/reference/tools/data-migration/configure/task-configuration-file-full/# 完整配置文件示例 2]

image

通过 information_schema.processlist 表和 information_schema.cluster_processlist 表查询连接,同一个连接,processlist 表中 txnstart 为空,cluster_processlist 表中 txnstart 字段是有值的,这个是正常的么?

版本:v4.0.0-beta-412-g6e2cbc025

答:这个只是对当前 select processlist / cluster processlist本身的语句才有这个问题, 因为 select processlist 是查memtable 那个算子不需要起事务,所以空,而 cluster 那个用的用的正常 tablereader 上层没感知下面表是真实表还是虚拟表都会启动事务所以有值…只有查 processlist/cluster process 本身才有这个问题

经测试符合预期:

image

调大 region size 的风险

答:

(1)热点调度不及时

(2)snapshot io 压力

(3)cop scan 时间长不利于并发

业务调研:分布式存储项目计划测试悲观锁,建议 v3.0.9 以上版本

sql 中出现 order by limit 1,索引选择可能走 order by 后面的索引

答:执行计划不稳定,limit 老问题,无论limit 多少

解决方案:

  1. 绑定 hints
  2. force index

3.0.13 预计修复执行带视图的 sql 连接直接断开

答:在 SQL 里把 View 写在 PartitionTable 前面,例如之前是 select * from partition_table, view where …; 改成 select * from view, parition_table where …。应该可以规避掉这个问题,但还是建议升级 TiDB 解决。

tidb2.1 升级 3.0问题 安装部署与监控

+1 推荐下《TiDB in Action》:https://book.tidb.io/session1/chapter1/tidb-architecture.html

答:

2.x 升级 3.x max-index-length 问题

升级时调大 max-index-length

2020年4月9日

目前 gc 是无法手动的

drainer.toml 更新后需要重启 drainer 进程

tiKV缩容 TiDB 运维手册

按照你提供的建议,我这边试了一下,发现没有什么变化,还是老样子,我的一个很大的疑问是,所有的节点的网络流量没有一个超过10MiB的,这个不合理,无论我怎么调整参数,网络流量,CPU使用都保证稳定,不会有太多变化,我怀疑是否tiKV底层针对region的snapshot有单独的处理队列(或者线程),而这个队列限制了这种迁移的速率。 如果调度的限制成倍的增大,但是监控上看没有引起什么变化的话,我有理由…

1 pd-ctl -u {pd_ip}:{pd_port} store limit {storeid} 32 (storeid 应该为不需要下线的节点的 storeid , 可以通过 pd-ctl -u {pd_ip}:{pd_port} store 查询)

2 region-schedule-limit 以及 replica-schedule-limit 调整到 64

3 注意线上节点的压力。如果压力升高的话可以把参数调整回来。

Mydumper 和 dm 需要 reload 权限,但由于各种原因不能赋权,可以指定 dm 指定 nolock参数

loader 导入中断造成数据一致性问题 数据迁移和数据同步

这边 tidb_loader.checkpoint 的更新时机是跟导入的 SQL 同一个事务内执行的。所以不会出现你说的问题。

答:

loader 导入过程中如果需要 断电宕机等因素导致 loader 终止,再次执行 loader 即可,因为:tidb_loader.checkpoint 的更新时机是跟导入的 SQL 同一个事务内执行的

2020年4月10日

tidb 数据同步到 hadoop:可以用 kettle、sqoop 等用于异构数据源之间数据同步,增量同步到其他异构数据源可以开启 tidb binlog 同步到 kafka,也可以 select … into outfile 导出为 csv 格式的文本

建立索引客户端不立即返回 应用适配和性能优化

我这边不会立马返回成功呢,要完全建完索引,才会返回成功,建了5个索引,都要1个多小时才能建完,返回sucess同时admin show ddl job 也会建完

添加索引不会立马返回成功是符合预期的,刚才确认了下 4.0 以及之前的版本都是这个行为,执行操作的命令返回 sucess,表示建索引完成。

慢查询日志里出现一条很早的txnStartTS TiDB 系统架构与原理

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。 【TiDB 版本】:TiDB-v3.1.0-rc 【问题描述】:查看tidb日志时,发现很多报错日志,有一个很早的txnStartTS [1586491363(1)] [1586490993] 若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

txnStartTS 转成 北京时间

[tidb@node5169 qihang.li]$ ./tools/bin/pd-ctl -u http://172.16.5.169:42379 tso 415888143313272835

system: 2020-04-10 10:56:03.103 +0800 CST

logic: 3

tiup升级连接丢失 安装部署与监控

目前无缝升级需要 LB 和应用配合实现,在滚动升级前将要操作的 TiDB 节点从 LB 上摘除,等会话执行完成后再对该 TiDB 做升级操作,升级完成后将 TiDB 节点添加回 LB,并确认有流量进来。

答:

基本达到线上升级标准。

目前无缝升级需要 LB 和应用配合实现,在滚动升级前将要操作的 TiDB 节点从 LB 上摘除,等会话执行完成后再对该 TiDB 做升级操作,升级完成后将 TiDB 节点添加回 LB,并确认有流量进来。

一台TiKV机器宕机后连接 TiDB特别慢/查询也特别慢 TiDB 系统架构与原理

TIDB 3.0.2以及以后的版本修复了一系列 TiDB 与 TiKV 之间网络连接出现异常的 bug,包括但不限于: region cache 相关:https://github.com/pingcap/tidb/pull/11344 tikvclient 相关:https://github.com/pingcap/tidb/pull/11531 https://github.com/p…

问题:一台 TiKV 机器挂掉后,连接 TiDB 要 hang 10 几秒,查询 1000 多条记录的表都没有返回结果

报错:

[2020/04/09 15:16:00.830 +08:00] [ERROR] [client.go:197] [“batchRecvLoop error when receive”] [target=down_tikv_ip:20164] [error=“rpc error: code = Unavailable desc = transport is closing”] [stack=“github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).batchRecvLoop\"n\"t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client.go:197”]

[2020/04/09 15:16:01.854 +08:00] [ERROR] [client.go:169] [“batchRecvLoop re-create streaming fail”] [target=down_tikv_ip:20164] [error=“rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = “transport: Error while dialing dial tcp down_tikv_ip:20164: i/o timeout””] [stack=“github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).reCreateStreamingClient\"n\"t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client.go:169\"ngithub.com/pingcap/tidb/store/tikv.(*batchCommandsClient).batchRecvLoop\"n\"t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client.go:203”]

答:

TIDB 3.0.2 以及以后的版本修复了一系列 TiDB 与 TiKV 之间网络连接出现异常的 bug,包括但不限于:

  1. region cache 相关:https://github.com/pingcap/tidb/pull/11344 2
  2. tikvclient 相关:https://github.com/pingcap/tidb/pull/11531
  3. https://github.com/pingcap/tidb/pull/11370

建议可以的话升级到 3.0 的最新 release 版本再进行观察。

2020年4月11日

github.com/pingcap/tidb

Issue: tidb-server refuses to start if no pump is registered with pd

opened by kolbe on 2019-04-23

Bug Report
Please answer these questions before submitting your issue. Thanks!

What did you do?
When trying to restart all TiDB cluster components simultaneously,...

如果 enable-binlog 为真,则 pump 实例必须可用。

如果我们使用配置 TiD​​B enable-binlog = true,建议的启动顺序为:PD -> TiKV -> Pump -> TiDB -> Drainer

2020年4月12日

选择存储引擎

EXPLAIN SELECT /*+ read_from_storage(tikv[t]) */ count(SUBSTR(name FROM 1 FOR 3) )FROM t;

SELECT /*+ read_from_storage(tiflash[t]) */ count(SUBSTR(name FROM 1 FOR 3) )FROM t;

2020年4月14日 10:15:30

tidb-server对于sql的内存占用限制 应用适配和性能优化

Hi @rongyilong-PingCAP,TiDB 4.0 RC 版本已经发布了,可以试试。我们在这个版本中默认支持了部分算子(比如 Hash Join)的中间结果落盘,这时候可以在不杀掉 SQL,也不过多使用系统内存的情况下执行完该 SQL 了。不过因为中间结果落盘了,执行性能会有所损失。

答:

  1. mem-quota-query 可以根据目前服务器的内存进行设置
  2. 该参数也需要和 oom-action=cancel 配合使用,避免 tidb server 出现 oom。

TiDB 4.0 RC 版本已经发布了,可以试试。我们在这个版本中默认支持了部分算子(比如 Hash Join)的中间结果落盘,这时候可以在不杀掉 SQL,也不过多使用系统内存的情况下执行完该 SQL 了。不过因为中间结果落盘了,执行性能会有所损失。

SQL执行出现reading initial communication packet', system error: 0 "Internal error/check 应用适配和性能优化

你好, 抱歉,暂时可从以下链接查看,我们会持续更新官网: https://github.com/pingcap/tidb/blob/c02e92c02f31d67da0c7c2e02031c920eb264313/config/config.toml.example#L234https://pingcap.com/docs/dev/reference/configuration/tidb-se…

一个事务中条目大小的限制(以字节为单位)。

如果使用TiKV作为存储,则该条目表示键/值对。

注意:如果启用binlog,则此值应小于104857600(10M),因为这是Pumper可以处理的最大大小。

如果未启用binlog,则该值应小于10737418240(10G)。

txn-total-size-limit = 104857600

【SOP 系列 01】 Release-2.1 升级到 Release-3.0 线上集群升级 TiDB 运维手册

01 Release-2.1 升级到 Release-3.0 线上集群升级 李仲舒 2020 年 2 月 10 日 一、背景 / 目的 分布式数据库集群运维过程有一定的复杂性和繁琐性,3.0 版本是目前被广泛使用的版本,相比 2.1 有大幅度增加性能,以及很多新增的功能和特性,整体架构、配置也有较大的优化。该篇根据广大用户的升级经验,尽可能将 Release-2.1 升级到 Release-…

答:

关于新增的 excessive_rolling_update.yml 和 rolling_update.yml 的关系:

如果部署采用 (默认)systemd 模式 ,使用 excessive_rolling_update.yml 来进行滚动升级操作,原因是涉及到 PD 滚动升级 1(以 v3.0.9 为例)的代码变动,该脚本仅本次升级使用一次,以后再次升级到后续版本均由 rolling_update.yml 来完成。

2020年4月15日

DM load报错 数据迁移和数据同步

[%E5%9B%BE%E7%89%87]

context canceled 是被中斷的意思,可能是 Ctrl+C 也可能是別的錯誤

如何让某一列的排序规则为大小写不敏感 应用适配和性能优化

【系统版本 & kernel 版本】 CentOS Linux release 7.6.1810 (Core) 4.20.10-1.el7.elrepo.x86_64 【TiDB 版本】 3.0.5 【问题描述(我做了什么)】 TiDB 列的排序规则 [image] 已有的数据 [image] 执行的sql语句 [image] 【我期望的】 MySQL 列的排序规则 […

new_collations_enabled_on_first_bootstrap

  • 用于开启新的 collation 支持
  • 默认值:false
  • 注意:该配置项只有在初次初始化集群时生效,初始化集群后,无法通过更改该配置项打开或关闭新的 collation 框架;4.0 版本之前的 TiDB 集群升级到 4.0 时,由于集群已经初始化过,该参数无论如何配置,都作为 false 处理。
0
0
0
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论