drainer不能写入下游TiDB

🪐 TiDB 技术问题 备份&数据迁移
1

上游系统是TiDB3.0.x 下游系统是4.0.0

目前在drainer 发现无法同步下去。大量这种报错

[2020/06/11 11:10:18.421 +08:00] [ERROR] [executor.go:111] ["exec fail"] [query="DELETE FROM `uniorder`.`uoc_order_pay` WHERE `id` = ? LIMIT 1"] [args="[88387127985037312]"] [error="Error 9002: TiKV server timeout"]

但是拿到这条语句去下游系统上执行是可以执行成功的。

刚修改了下打的位置，如果打到haproxy就会有这个问题。打到tidb的ip就可以了

2
  1. drainer 配置文件里是什么 ip ？
  2. 打的位置是指，配置 HA 的 IP有报错，直连配置 tidb 没有报错吗？
3

1、drainer配置里目前是TiDB的IP，能正常导入，该方法暂时决绝了报错问题。 2、当drainer 目标IP是 haproxy的时候，drainer会报tikv server timeout的错误，出问题的时间点是今天早上9点14分左右，然后一直报该错误。 3、该错误能在4.0的grafana监控中体现。

4
  1. 使用 haproxy ip 测试是否能够正常导入，是一直报 tikv server timeout 还是说这个特点时间报错了
  2. 查看 tidb 和 tikv 日志，看看是否在这个时间段有报错，多谢。
5

是使用haproxy进去会报错，同个时间通过TiDB进去能正常。tidb的日志翻到的就是tikvserver timout。而tikv暂时没发现。

6

辛苦上传下 tidb.log 和 tikv.log 在 sql 执行失败时间点的日志把，这边看下，tidb 执行语句到 tikv ，如果 tidb 中有报错信息，tikv 一般也会出现，请确认下各个 tikv 节点的日志。

7

logs.tar (62 KB)

我从dashboard上下载了9点到11点15的error级别日志。看起来只有一台TiDB在报错。
drainer的流量是打到134的。

8
  1. 看这里有一些报错是，在 sql_mode=only_full_group_by 下 group by 的条件不完善。 请检查你的sql_mode.

[2020/06/11 10:16:50.185 +08:00] [Error] [conn.go:728] [“command dispatched failed”] [conn=2381] [connInfo=“id:2381, addr:10.204.40.82:60126 status:10, collation:utf8_general_ci, user:uniorder”] [command=Query] [status=“inTxn:0, autocommit:1”] [sql=“SELECT STATE AS 状态, ROUND(SUM(DURATION),7) AS 期间, CONCAT(ROUND(SUM(DURATION)/0*100,3), ‘%’) AS 百分比 FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=0 GROUP BY STATE ORDER BY SEQ”] [txn_mode=PESSIMISTIC] [err="[planner:1055]Expression #1 of ORDER BY is not in GROUP BY clause and contains nonaggregated column ‘’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

9

这个虽然报错但是不影响查询返回的值，暂时没找到怎么去解决。

但是这个出问题时间是9点14分左右，直接使得drainer挂了

10

麻烦通过官方文档查看 SQL_MODE 关于 only_full_group_by 的介绍，目前问题比较清晰，应该是上下游的 SQL_MODE 不一致造成的。