为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
你好，
请上传下 tidb.log 文件，可能是执行 sql 时，出现问题。
可以自行将 sql_mode 设置为 ‘’ ，看是否能解决。
这个sql_mode设置为空，会不会影响0000-00-00 00:00:00这种日常的插入啊？
已经将sql_mode置为空了。看看效果，不行再改回去。
已经试过，将其置为空，重新stop-task、start-task后，问题已经存在
你好，
查看 dm-worker.log 其中存在大量的表已创建的报错，建议
现在已经完成了38.37%，清空数据是指将，现在数据库当中所有的表中数据都清理掉？还是将所有表都drop掉？这个同步任务涉及7个数据库。
你好，
请问当前 mydumper 出来的数据大概多大？
tidb.log 中存在 ‘Region is unavailable’，可以看下 tikv 的状态是否太过繁忙，可以上传下监控中 overview - tikv 面板
从 query-status 和 dm-woker.log 看，存在 ddl 冲突，频繁的重试增大了 tidb 的压力，也是有可能的。
确认以上问题后，这边可以看接下来怎么做好些
你好，
通过监控，看到目前集群 leader 出现大量迁移，请执行并返回下结果，确认下 118 的 leader_score 与其他节点是否有很大差异
./tidb-v4.0.0-rc-linux-amd64/bin/pd-ctl -u http://172.16.5.169:22379 store
[tidb@kaikaitidb1 bin]$ ./pd-ctl -u http://10.7.110.114:2379 store
{
“count”: 3,
“stores”: [
{
“store”: {
“id”: 1,
“address”: “10.7.110.117:20160”,
“version”: “3.0.5”,
“state_name”: “Up”
},
“status”: {
“capacity”: “787.3GiB”,
“available”: “708.1GiB”,
“leader_count”: 359166,
“leader_weight”: 1,
“leader_score”: 441621,
“leader_size”: 441621,
“region_count”: 375090,
“region_weight”: 1,
“region_score”: 461278,
“region_size”: 461278,
“start_ts”: “2020-05-13T08:59:19+08:00”,
“last_heartbeat_ts”: “2020-05-13T09:17:05.366187782+08:00”,
“uptime”: “17m46.366187782s”
}
},
{
“store”: {
“id”: 4,
“address”: “10.7.110.119:20160”,
“version”: “3.0.5”,
“state_name”: “Up”
},
“status”: {
“capacity”: “787.3GiB”,
“available”: “710.4GiB”,
“leader_count”: 11861,
“leader_weight”: 1,
“leader_score”: 14020,
“leader_size”: 14020,
“region_count”: 377530,
“region_weight”: 1,
“region_score”: 458212,
“region_size”: 458212,
“receiving_snap_count”: 1,
“start_ts”: “2020-05-13T09:14:59+08:00”,
“last_heartbeat_ts”: “2020-05-13T09:17:02.357081996+08:00”,
“uptime”: “2m3.357081996s”
}
},
{
“store”: {
“id”: 5,
“address”: “10.7.110.118:20160”,
“version”: “3.0.5”,
“state_name”: “Up”
},
“status”: {
“capacity”: “787.3GiB”,
“available”: “713.6GiB”,
“leader_count”: 190350,
“leader_weight”: 1,
“leader_score”: 234804,
“leader_size”: 234804,
“region_count”: 370138,
“region_weight”: 1,
“region_score”: 461404,
“region_size”: 461404,
“start_ts”: “2020-05-13T09:06:04+08:00”,
“last_heartbeat_ts”: “2020-05-13T09:16:57.427564841+08:00”,
“uptime”: “10m53.427564841s”
}
}
]
}
你好，
grafana监控界面在截图时，工具不好用，都保存到excel里面了。三个tivk的日志也上传了。
tikv_117.log (4.1 MB)
tikv_118.log (3.5 MB) tikv_119.log (4.1 MB) grafana界面指标.xlsx (3.1 MB)
你好，
根据 overview 中 region health 显示 empty-region-count 为 559k，在数据占用仅为 80G 上下的 集群来说已经很多了。请根据以下链接开启 region merge 看是否可缓解 tikv 繁忙的问题。
https://pingcap.com/docs-cn/stable/reference/best-practices/massive-regions/#-region-merge
已经开启了region merge。TiDB集群中TiDB服务器总是重启，rongyilong同事帮忙解决的，在解决时开启了这个。
你好
ok，开启之后看来还没合并
可能还没有达到合并阈值，需要调小
还有可能之前做过 drop 或者 truncate table 操作，导致有很多空表，目前默认情况，空表的region 是不自动合并的需要增加以下两个参数。（你可以先调整这两个参数，看效果不行就调小 region size 的阈值）
PD 参数 namespace-classifier = “default”
TiKV 参数 split-region-on-table: false
可以在中控节点修改 pd.yml 然后执行 ansible-playbook rolling_update.yml --tags=pd 来使修改生效或者 edit-config 之后通过 tiup cluster cluster-name reload -R pd。
麻烦反馈下一下信息和展示信息
将下图信息展示下：
修改配置：（通过ansible-playbook rolling_update.yml --tags=pd
ansible-playbook rolling_update.yml -t tikv 这两个命令重启的）
上面命令没有执行时的数量：
按照上面的配置修改成功。
