check drop column failed

OceanBase
#1

社区版3.1.5，执行删除列的时候，报错 check drop column failed，日志除了 check drop column failed没有其他提示，我根据文档查看了合并的状态，所有4个zone都是IDLE，列不是主键，也没有索引。所有的节点都是active，还有什么原因会导致这个问题，怎么排查

#3

出现该报错一般由以下原因：

  1. 确认删除字段是否为主键与索引字段。
  2. 合并任务没有完成导致删除失败，待合并完成即可重新进行删除操作，常见于这种。可从表 __all_zone 中查询各个版本号来确认。
  3. 排查 OceanBase 数据库功能问题。根据报错查询日志，排查流程如下。
  4. 执行 alter table 命令的节点先执行，检查语法。
  5. 语法通过后，通过 RS 来执行 DDL，所有 DDL 都通过 RS 节点执行。所以 DDL 失败的问题，执行命令的节点和 RS 节点的日志是关键。
  6. 如果带有备集群的话，还要考虑下备集群的合并状态是否正常，不正常也会导致删除列失败。如果主备集群合并版本差异太大的话，备库会从老版本追上去，但是不会跨版本，所以差异太大的话可能追齐合并耗时会很久。
#4

我是通过proxy连接执行的语句，是不是连接的就是RS节点，如题日志，索引，合并都检查过了，没有备集群。还会有其他原因吗，或者注意的地方

#5

直接连observer执行试试呢

#6

如果 SQL 执行立刻报错的，推荐使用系统租户获取 trace_id。
1. 登录系统租户，打开enable_rich_error_msg 参数
alter system set enable_rich_error_msg=true;
2. 登录业务租户，执行报错 SQL 语句，会直接返回执行节点 IP 和 trace_id 信息。
obclient [test]> select count(*) from t2; ERROR 1146 (42S02): Table 'test.t2' doesn't exist [xx.xx.xx.1:2882] [2024-04-13 20:10:20.292087] [YB420BA1CC68-000615A0A8EA5E38-0-0]
3. 去 xx.xx.xx.1 节点过滤日志，如果最新日志无法过滤到，可以正则匹配多个日志进行过滤
[root@x.x.x.1 ~]$ grep "YB420BA1CC68-000615A0A8EA5E38-0-0" rootservice.log [root@x.x.x.1 ~]$ grep "YB420BA1CC68-000615A0A8EA5E38-0-0" observer.log
4. 获取完日志信息后，关闭enable_rich_error_msg参数
alter system set enable_rich_error_msg=false;

#7

按照此方法我查看了日志：WARN check_can_alter_column (ob_ddl_service.cpp:4798) [472][474] [YBxxxxxxx] [lt=18] [dc=0] check drop column failed

#8

只记录了这一条，没有其他日志信息

#9

日志级别是WDIAG级别吗，如果不是，可以syslog_level 参数设置下，再取下日志看看。