oms 4.2.10 ,从mysql5.7迁移数据到ob ce 4.3.5.3, foreign key表结构迁移失败

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】mysql 模式
OceanBase_CE 4.3.5.3 (r103000092025080818-e8da5f0afb288ed0add0613740c6ccf2a3c6830b) (Built Aug 8 2025 18:43:02)
【问题描述】oms 4.2.10 ,从mysql5.7迁移数据到ob ce 4.3.5.3
【复现路径】迁移过程部分数据库结构迁移成功,部分迁移失败,如( keycloak,flowable)
【附件及日志】

(conn=3221555262) Table doesn’t exist Query: – [WARN] [CONVERT] The table charset: utf8 → utf8mb4

– [WARN] [CONVERT] The table collation: utf8_general_ci → utf8mb4_general_ci

create table REALM (

ID varchar(36) not null,

ACCESS_CODE_LIFESPAN int(11),

USER_ACTION_LIFESPAN int(11),

ACCESS_TOKEN_LIFESPAN int(11),

ACCOUNT_THEME varchar(255),

ADMIN_THEME varchar(255),

EMAIL_THEME varchar(255),

ENABLED bit(1) not null default b’0’,

EVENTS_ENABLED bit(1) not null default b’0’,

EVENTS_EXPIRATION bigint(20),

LOGIN_THEME varchar(255),

NAME varchar(255),

NOT_BEFORE int(11),

PASSWORD_POLICY varchar(2550),

REGISTRATION_ALLOWED bit(1) not null default b’0’,

REMEMBER_ME bit(1) not null default b’0’,

RESET_PASSWORD_ALLOWED bit(1) not null default b’0’,

SOCIAL bit(1) not null default b’0’,

SSL_REQUIRED varchar(255),

SSO_IDLE_TIMEOUT int(11),

SSO_MAX_LIFESPAN int(11),

UPDATE_PROFILE_ON_SOC_LOGIN bit(1) not null default b’0’,

VERIFY_EMAIL bit(1) not null default b’0’,

MASTER_ADMIN_CLIENT varchar(36),

LOGIN_LIFESPAN int(11),

INTERNATIONALIZATION_ENABLED bit(1) not null default b’0’,

DEFAULT_LOCALE varchar(255),

REG_EMAIL_AS_USERNAME bit(1) not null default b’0’,

ADMIN_EVENTS_ENABLED bit(1) not null default b’0’,

ADMIN_EVENTS_DETAILS_ENABLED bit(1) not null default b’0’,

EDIT_USERNAME_ALLOWED bit(1) not null default b’0’,

OTP_POLICY_COUNTER int(11) default ‘0’,

OTP_POLICY_WINDOW int(11) default ‘1’,

OTP_POLICY_PERIOD int(11) default ‘30’,

OTP_POLICY_DIGITS int(11) default ‘6’,

OTP_POLICY_ALG varchar(36) default ‘HmacSHA1’,

OTP_POLICY_TYPE varchar(36) default ‘totp’,

BROWSER_FLOW varchar(36),

REGISTRATION_FLOW varchar(36),

DIRECT_GRANT_FLOW varchar(36),

RESET_CREDENTIALS_FLOW varchar(36),

CLIENT_AUTH_FLOW varchar(36),

OFFLINE_SESSION_IDLE_TIMEOUT int(11) default ‘0’,

REVOKE_REFRESH_TOKEN bit(1) not null default b’0’,

ACCESS_TOKEN_LIFE_IMPLICIT int(11) default ‘0’,

LOGIN_WITH_EMAIL_ALLOWED bit(1) not null default b’1’,

DUPLICATE_EMAILS_ALLOWED bit(1) not null default b’0’,

DOCKER_AUTH_FLOW varchar(36),

REFRESH_TOKEN_MAX_REUSE int(11) default ‘0’,

ALLOW_USER_MANAGED_ACCESS bit(1) not null default b’0’,

SSO_MAX_LIFESPAN_REMEMBER_ME int(11) not null,

SSO_IDLE_TIMEOUT_REMEMBER_ME int(11) not null,

primary key (ID),

constraint UK_ORVSDMLA56612EAEFIQ6WL5OI unique key (NAME),

constraint FK_TRAF444KK6QRKMS7N56AIWQ5Y foreign key (MASTER_ADMIN_CLIENT) references CLIENT (ID) ON DELETE RESTRICT ON UPDATE RESTRICT

)

default charset=utf8mb4

default collate=utf8mb4_general_ci Parameters: []

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!

是外键表迁移失败了吗,重试全部失败对象试一下,看下失败的表对象有没有减少

2 个赞

外键存在依赖的肯定有概率会报错,重试就行了,如果存在循环依赖的就需要手动处理,先去掉外键的依赖,表结构迁移完成,手动创建依赖

4 个赞

带有外键的表结构都不成功,删除外键后,表结构能迁移成功

1 个赞

重试失败的对象可以吗,外键表因为创建顺序的问题是有可能失败的,一般重试就可以成功

1 个赞

重试多次后,仍有部分需要手动操作的

1 个赞

那应该是外键表的顺序可能有问题 没有能重试过去 手动处理一下

如果你的有些表存在相互依赖形成一个环的话,你重试多少次都没有,需要先去掉某个表的依赖,先把表创建成功,然后在重试,成功之后,最后把去掉的依赖在加上

1 个赞

看看

重试多次后,最终只有一个表手动处理,
迁移过去后,在OB里面alter table 加上就好了