如果没有接入业务，可否把 general log 打开，确认下是什么操作导致的这个报错么
2 个月前
是否确定是这个报错导致的 leader 切换？
我翻了下之前貌似有相同的情况，不过 bug 貌似被修复了
2 个月前
我的环境也是 651 没有遇到这个报错，请问这个报错对 TiDB 集群有什么影响吗？
2 个月前
观察 “region_count”: 是否有减小的趋势，直到归 0 变为 tomestone 状态
可修改如下参数进行加速，x根据负载自行根据现在的数值调整：
config set region-schedule-limit x
config set replica-schedule-limit x
config set leader-schedule-limit x
config set max-pending-peer-count x
config set max-snapshot-count x
config set merge-schedule-limit x
2 个月前
不是，这是表结构和数据类型的限制，我的意思是如下文本最大能到多少，还是说没有限制
select col1,col2.....colN from t1 inner join t2 where 1=1 and 1=1 and 1=1 and 1=1 and 1=1 and 1=1 and 1=1 and 1=1 and 1=1 and ....
2 个月前
建议重点测试业务驱动变更到新版本后是否有适配问题、SQL 语句的兼容性、是否有性能回退的情况
根据您提供的业务场景有如下几个方案可供参考
逻辑导入方式
源库4.x：逻辑备份（dumpling）sql 文件
目标端 6.5：逻辑导入（lighting）sql，据说 6.5 有 10 倍左右的性能提升
物理导入的方式
源库4.x：br工具导出
目标端同版本 4.x: br 工具导入
目标端同版本 4.x: 离线升级（–offline）5x，再离线升级到 6x
不停机维护方式
使用逻辑导入导出的方式（规避了br工具兼容性问题），然后使用 ticdc 进行同步（我记得 …
2 个月前
就你的问题个人感觉
这样操作可以吗？
可以，ticdc只是根据当前 tso 来抓取变更的工具（只要 tso 没有被 gc 掉）
能成功还是会报错？
个人感觉会成功，但不久后，ticdc 在同步 db2 的增量数据时，会有对已备份的db2中的数据发生冲突，导致 ticdc 的任务停止
针对如上场景有两种方案可以参考：
用 br 备份 db1 和 db2，获得统一的 tso （前提是在同一实例下）
如果不在同一实例，需要启动两个 ticdc，分别同步 db1 与 db2
3 个月前
经测试，是密码中含有特殊字符，sink 参数 sasl-password 对特殊字符处理的逻辑有待完善。5.4 和 6.5 都有相同的问题，用户在设置密码中不可避免采用特殊字符，希望兼容
3 个月前
没有更多内容了