drop database db_name; 一直卡主

OceanBase
,
#1

【 使用环境 】生产环境
【 OB or 其他组件 】obproxy
【 使用版本 】4.2.0
【问题描述】租户使用 obp 链接后，执行 drop database aa_2190; 后一直卡主，退出后，重新执行命令报 ERROR 4017 (HY000):Duplicate entry ‘500002-500002-1695020344750624’ for key ‘idx_task_key’ 错误
【复现路径】drop database aa_2190;
【问题现象及影响】

【附件】
1 个赞
#3

自己查表可以看出 500002-500002-1695020344750624 这个的确是重复主键了？ 那说明导入的时候就有问题了吧

1 个赞
#4

不是的，字面意思是我创建了两个一模一样的 drop database 的 task

#5

有比较简单的快速复现操作么，必现么？把复现sql发下，你的版本是多少，部署方式是怎么样的？租户配置也贴下

#6

直连observer会出现这种情况么？ obproxy的部署方式是怎么样的

#7

使用的是 obproxy 链接的
部署方式：通过命令行部署，使用的是 all-component 的方式部署。
三个节点，都部署了 obproxy 和 observer

#8

版本：4.2.0
复现路径：

  1. 使用命令行部署，配置文件为 all-compone
  2. 使用 ocp 创建租户 test，设置租户 root 密码
  3. 使用 OMS，迁移 MySQL 数据库至 ob 的 test 租户中
  4. 使用数据库链接工具 sqlpro，用 obproxy 的方式链接 test 租户的数据库，然后删除迁移过来的数据库 db1 —— 会一直等待
  5. 进入 OB 节点，使用 obp 链接数据库，执行 drop database db2 命令 —— 还是会一直等待；执行 drop database db1；会报 Duplicate entry ‘500002-500002-1695020344750624’ for key ‘idx_task_key’
#9

第3步迁移结束且成功了么？可以简单看下库存下的表和表行数select count(*)看下符合预期么，也可以看下oms迁移的状态，第4步一直等是什么意思，也是不成功的意思么？

#10

第三步迁移成功。
一直等表示执行没有结果，处于卡主的状态

#11

方便说下你这个库大概的数据量情况么？多少张表，每张表大概的数据量？ 我怀疑是没成功的，所以导致无法删除。 你可以试下单独先删下这个库下某张体量比较小的表试下

#12

从数据量来看，数据迁移是没问题的
有没有办法删除对应的 task

#13

select * from oceanbase.__all_virtual_processlist;

查下活跃的任务

#14

image
image1290×323 18.5 KB

使用 delete from table_name; 是可以删除表中的数据，但使用 drop tables table_name;又会卡主

#15

我把系统时间校准后，可以正常删除了 :joy: