OceanBase从3.2.4.5迁移到4.2.1.2

前言：

业务没有真实上线，原本的OB环境为3.2.4.5，业务要求升级集群版本到4.x，因为很多测试数据都在该环境上所以需要迁移3.x数据到4.x。（业务租户为OB_ORACLE）

该篇文章也算记录下迁移的整个流程。

前期准备：

1.先确认需要迁移的用户

2.目标端集群创建相应的用户

3.确认oms资源以及迁移的数据量，梳理有没有数据量比较大的表

select  table_id,sum(size)/1024/1024/1024 data_size from  __all_virtual_table_mgr where table_type=1  and table_id in (
select table_id from gv$table where database_name in( 'USER_NAME'))  group by table_id order by   data_size desc  limit 30;

###该语句可以查询比较大的表，我这里查询的是top30的表，其实因为集群参数kept_version_num是2加上集群为三副本，所以实际的major数据大小要除以6

4.梳理用户权限

######所有用户 grant resource,connect to username;
#####检查需要role
select distinct t.GRANTED_ROLE from dba_role_privs t where t.GRANTEE in (‘username’);
####查询role授权
select 'grant '||lower(t.GRANTED_ROLE)||' to '||t.GRANTEE||';' from dba_role_privs t where t.GRANTEE in ('ROLE_name') and GRANTED_ROLE not in ('CONNECT','DBA','RESOURCE','CONNECT') order by t.GRANTED_ROLE;
#######查询系统授权
--查询用户的
select 'grant '||lower(t.privilege)||' to '||grantee||';' from dba_sys_privs t where t.GRANTEE in ('username') and privilege not in ('ADVISOR','ALTER SYSTEM','ANALYZE AN','CREATE PUBLIC DATABASE LINK','DEBUG CONNECT SESSION','UNLIMITED TABLESPACE') order by t.privilege;
--查询role的
select 'grant '||lower(t.privilege)||' to '||grantee||';' from dba_sys_privs t where t.GRANTEE in ('role_name') and privilege not in ('ADVISOR','ALTER SYSTEM','ANALYZE AN','CREATE PUBLIC DATABASE LINK','DEBUG CONNECT SESSION','UNLIMITED TABLESPACE') order by t.privilege;
############查询对象权限
----------用户的
select 'grant '||privilege||' on '||owner||'.'||table_name||' to '||grantee||';' from dba_tab_privs t where t.grantee in ('user_name') and privilege not in ('FLASHBACK','DEBUG','REFERENCES','ON COMMIT REFRESH','QUERY REWRITE'); ----------role的
select 'grant '||privilege||' on '||owner||'.'||table_name||' to '||grantee||';' from dba_tab_privs t where t.grantee in ('role_name') and privilege not in ('FLASHBACK','DEBUG','REFERENCES','ON COMMIT REFRESH','QUERY REWRITE');

5.梳理迁移对象

select  owner, OBJECT_TYPE,STATUS,count(*)   from  dba_objects where owner 
in  ( 'USER_NAME') and  OBJECT_TYPE not like 'TABLE%' and OBJECT_TYPE not like  'INDEX%' and  OBJECT_TYPE<>'DATABASE' group by owner, OBJECT_TYPE,STATUS order by owner;
select  owner, count(*)   from  dba_types where owner in  ( 'USER_NAME')  order by owner;
select  owner, count(*)   from  dba_triggers where owner in  ( 'USER_NAME')  order by owner;

数据迁移：

1.oms配置调整（使用版本4.2.1）

>oms的docker资源调整，如果创建的时候给的比较大的话就不用调整了

>全量迁移参数调整，我为了全量迁移的时候快点，就把内存参数和连接数调大了

2.数据源配置，因为我这边源端和目标端都是未上线环境，所以直接配置的主库正常节点的proxy地址，如果是生产的话，可能要考虑备集群或者只读副本等方案，避免对主库的业务影响，相应的要拉取增量还要配置迁移用户，包括业务租户和sys租户

######业务租户#########
create user '__OCEANBASE_INNER_DRC_USER'@'%' IDENTIFIED BY uy1n8666;

grant ALL to '__OCEANBASE_INNER_DRC_USER';

grant select on sys.dba_tables to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_part_tables  to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_part_key_columns to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_subpart_key_columns to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_tab_partitions to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_objects to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_tab_subpartitions to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_indexes to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_ind_columns to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_constraints to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_tab_columns to '__OCEANBASE_INNER_DRC_USER';
grant select on sys.dba_tables to '__OCEANBASE_INNER_DRC_USER';
#####sys租户##############
create user oms_drc identified by 'uy1n8666';
grant all privileges on *.* to oms_drc;

3.把需要迁移的表进行链路拆分，根据数据量和表的个数

我这边把top30的表根据大小分成了两个链路，单独迁移。

其他的一些表数据量没那么大，按照用户拆分，在没有单表很大的情况下保证每个链路表在1200以内（为了迁移效率和触发白名单过长的问题，也可以通过规则匹配规避白名单过长的校验）。

有些特殊字段类型的表如UROWID无法迁移这类让业务确认，是否改造和手工迁移结构，因为我这时ob迁移到ob所以这类的问题比较少。

4.参数调优

大表链路有时候默认配置会造成链路延迟甚至中断，所以做了store的一些参数优化。（如果是oracle迁移ob的话，oracle store优化排查方式官网有的）

liboblog.formatter_thread_num=25
liboblog.dml_parser_thread_num=15
liboblog.sequencer_thread_num=7
liboblog.memory_limit='32G'

liboblog.part_trans_task_active_count_upper_bound = 400000
liboblog.part_trans_task_reusable_count_upper_bound=102400
#####部分链路的jvm我也调大了######

结构迁移：

在用户创建之后，表结构迁移完，基本上可以把权限给一遍了，方便对象迁移不会因为权限报错。

ob迁移到ob就不需要dbcat导对象了，可以直接使用obdump来迁移对象。

###导出对象###
./obdumper --ddl -h10.111.111.11 -P3306 -usys -tXXXXXX -cXXXXXX -p'TXXXXXX' --sys-password='XXXXXX' -D XXXXXX --view ' * '    --synonym ' * '  --type ' * '  --type-body ' * '  --package ' * '    --package-body ' * '   --function ' * '  --procedure ' * ' -f /home/XXXXXX/ob-loader-dumper-4.2.7-RELEASE/output/outputXXXX


###割接时导出对象### 因为触发器提前导入可能会导致数据不一致，序列的话提前导入，数据可能会从生产端产生更新的序列，造成业务报错，所以要在割接的时候导入
--sequence ' * '  --trigger ' * '

./obdumper --ddl -h10.111.111.11 -P3306 -usys -tXXXXXX -cXXXXXX -p'TXXXXXX' --sys-password='XXXXXX' -D XXXXXX --sequence '*'  --trigger ' * '  -f /home/XXXXXX/ob-loader-dumper-4.2.7-RELEASE/output	

####导入对象
./obloader --ddl -h10.111.111.21 -P3306 -usys -tXXXXXX -cXXXXXX -p'TXXXXXX'  --sys-password='XXXXXX' -D XXXXXX --view '*'    --synonym '*'   --package '*'    --package-body '*'   --function '*'  --procedure '*'  -f /home/XXXXXX/ob-loader-dumper-4.2.7-RELEASE/output/outputXXXX

#####也可以用all导入
./obloader --ddl -h10.111.111.21  -P3306 -usys -tXXXXXX -cXXXXXX -p'TXXXXXX'  --sys-password='XXXXXX8' -D XXXXXX --all  -f /home/XXXXXX/ob-loader-dumper-4.2.7-RELEASE/output/outputXXXXXX
######如果因为权限之类的报错的话，补充完权限后，可以重新导入下，因为obload导对象，默认校验对象是否存在，存在的话就不会执行了，所以想重新编译可以加--replace-object 参数让它执行替换操作
./obloader --ddl -h10.111.111.21  -P3306 -usys -tXXXXXX -cXXXXXX -p'TXXXXXX'  --sys-password='XXXXXX' -D XXXXXX  --procedure '*'  --replace-object  -f /home/XXXXXX/ob-loader-dumper-4.2.7-RELEASE/output/outputXXXXXX

等对象导完，检查数量及状态没有问题，就可以准备割接了。当然生产环境要进行几轮的模拟割接等，要业务进行压测，业务测试，还要配合进行高可用测试/IO测试等等，这里就不详细介绍了。

总结：

该篇主要是为了记录下，也希望帮助其他同学了解迁移的流程，也希望ob能有更好的大版本的升级方案。

行之所向，莫问远方。