这个您了解了没 ？？？
版本升级，具有强绑定的性质。 包含升级的方法。 OCP 升级版本不是万能的。
OceanBase 社区已接收您的帖子，正在跟进中。
在 OB社区专家的支持下，问题解决了，非常感谢！
总结一下。
- 问题现象是一个子任务的日志提示先成功后失败。
Set state for subtask: 9171685, operation:RETRY, state: SUCCESSFUL
Set state for subtask: 9171685, operation:RETRY, state: FAILED
事后多个子任务出现类似现象，任务并不固定。
- 首先排查子任务 upgrade_health_checker 是否真的失败了。
根据日志信息，登录 OB 节点做这个检查
python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u root@sys -pxxxxxxx
从结果看，并无报错。
所以确认这一步问题跟业务OB无关。
那么怀疑方向就是 OCP 自身。
-
分析 OCP 的日志
ocp-server.log能看到一些异常信息。
这里面日志很多，有点乱。最终对我没用（对产品研发有用），就忽略了。 -
分析 OCP 元数据租户
ocp_meta的元数据库meta_database。抓取 sql 审计视图，发现跟这个任务有关的两笔 update 记录。
可以确认 OCP 是先认为任务成功了 后20秒后又认为失败了。并且根据 session_id 字段判断是两个不同的客户端连接更新导致。
多次重试都是如此，由此推断是 OCP 新版本的任务框架出了问题。可能用了某种并发技术（协程？），没有处理好导致随机出现这种报错。
后面其他子任务也随机出现了这个现象。
这也解释了为什么 OCP 的日志里有时候会出现 lock wait timeout 等记录。这种并行的更新，可能自己阻塞了自己（OCP 里日志里还能找到第三句 update ，是将 state 更新为 pause 记录的。但是 SQL audit 里看不到，推测是这个更新被阻塞了，然后超时回滚了。
- 解决办法
订正任务父子表记录。
begin; update task_instance set state='RUNNING' where id=7941627;update subtask_instance set state='SUCCESSFUL' where id=9171678;
commit;
- OCP 页面刷新任务，点击【继续】。
4 个赞
感谢反馈这个问题，后续我们确定根因了再同步给您。
1 个赞
问题原因：对于升级场景下 挂起|继续 逻辑处理存在异常，导致子任务执行成功跟标记子任务挂起状态事务冲突，进而因为事务超时而将子任务标记成异常
临时处理：手动修改正 db 中子任务状态接口
bug修复方案：修正子任务状态处理逻辑，避免事务冲突
bug修复版本：OCP 4.3.6
3 个赞
实践出真知，感谢分享实战经验
宝贵的经验分享，谢谢！
内容很好
感谢作者的整理和分享
感谢作者的整理和分享
期待更多分享
写得很详细
内容很好
宝贵的经验分享，谢谢！
经验分享很有价值
实践出真知，感谢分享实战经验
宝贵的经验分享，谢谢！