其他数据库迁移至 OceanBase 数据库最佳实践

本文介绍如何从其他数据库迁移数据至 OceanBase 数据库。 本文将首先介绍常规的全量迁移和增量迁移方法，然后提供性能优化方法供参考，最后给出迁移的实践案例。

我们推荐您使用 OceanBase 提供的数据迁移服务（OMS）进行其他数据库至 OceanBase 数据库的迁移。更多信息，参考 OceanBase 迁移服务文档。

数据迁移流程

按以下步迁移数据：

1. 完成准备工作。

   使用 OMS 迁移数据前，您需要对源或目标数据库进行创建迁移用户、为用户授权等准备工作。详情请参见 创建数据库用户。

2. 新建数据源。

   在 OMS 控制台，分别新建源端和目标端的数据源。详情请参见 新建数据源。

3. 新建数据迁移项目。

   根据业务需求，在数据迁移项目中选择源端、目标端、迁移类型和迁移对象。迁移类型包含结构迁移、全量迁移、增量同步、全量校验和反向增量。详情请参见对应类型的数据迁移项目文档。

4. 通过预检查后，启动数据迁移项目。

5. 查看数据迁移项目的状态。

   数据迁移项目启动后，会根据选择的迁移类型依次执行。详情请参见 查看数据迁移项目的详情。

6. （可选）停止并释放数据迁移项目

   确认数据迁移项目成功，并不再需要同步源库和目标库的数据后，您可以清理当前的数据迁移项目。详情请参见 释放和删除数据迁移项目。

性能调优

本节将通过性能调优优化 OMS 的数据迁移效率。调优分为三个方面：源端规格、目标端规格和 OMS 调优。

源端规格

首先，通过监控工具查看源端数据库的性能，确定是否存在瓶颈。

监控指标

• CPU 使用率：查看 CPU 资源是否被耗尽。
• 内存使用：确保内存足够且未出现内存泄漏或溢出。
• 磁盘 I/O：检查是否有磁盘瓶颈，影响数据读取速度。
• 网络带宽：确保网络传输速度不受限。

调优方法

1. 升级硬件配置：

   • 增加 CPU 核心数。
   • 扩充内存容量。
   • 使用更高性能的磁盘（如 SSD）。

2. 优化数据库配置：

   • 调整缓冲区大小、连接池等参数。
   • 清理未使用的索引和表。
   • 执行必要的数据库维护，如重建索引、分析表等。

3. 查询优化：

   • 分析慢查询并进行优化。
   • 使用索引提升查询性能。
   • 将复杂查询拆分为多个较小的查询。

目标端规格

与源端类似，通过监控工具查看目标端数据库的性能数据，确定是否存在瓶颈。

OceanBase 优化建议：

OMS 调优

在确认源端和目标端没有瓶颈后，可以通过调整 OMS 组件和并发度来提高性能。

优化 OMS 机器资源

• 确保 OMS 机器的 CPU、内存和网络带宽等资源充足，以便设置更高的链路任务并发数。
• 使用多台机器部署 OMS，以分散各个组件的任务，提高整体性能。

调优组件

1. 调整并发：

   OMS 通过调整并发的方式实现对 CPU 使用的限制，无强制的 CPU 隔离能力，在多链路高压力的环境下可能造成 CPU 争用严重。调整 OMS 任务的并发度，增加并发任务数以提高数据传输速度。

   并发度一般和机器 CPU 核数相关，最大可以设置成 CPU*4。设置并发时，请考虑机器上是否运行其他任务。全量迁移建议更改目的端并发，多数情况是目的端存在瓶颈。如果源端存在瓶颈再调整源端并发。

   全量迁移并发调整：

   

   增量同步并发调整：

   

   在 connector 任务目录下运行 ./connector_utils.sh metrics 查看 metrics 信息，其中 DISPATCHER: wait record:0, ready batch:0 中，如果 wait record 是 0 或者非常低比如 100 以内就是源端瓶颈，如果 ready batch 比较多则是目的端瓶颈。如果 wait record 比较多但是没有 ready batch 可能是存在热点。

2. 任务拆分：

   将大表或复杂表的数据迁移任务拆分为多个较小的任务，以提高传输效率。

3. 增量同步配置：

   调整 store 和 Incr-Sync/Full-Import，以优化增量同步性能。OMS 的增量由 Store 和 Writer 组件组成，Store 负责源端解析日志，Writer 负责目标端数据写入。因此 Store 在全量迁移开始时拉起，Writer 在全量结束后拉起。

   Store 解析有问题可以尝试调整以下参数：

   deliver2store.logminer.fetch_arch_logs_max_parallelism_per_instance=日归档/500g +1
   deliver2store.logminer.max_actively_staged_arch_logs_per_instance=上述参数*2
   deliver2store.logminer.staged_arch_logs_in_memory=true  //需要配合调整 JVM，若有大事务可开启减少落盘
   deliver2store.logminer.max_num_in_memory_one_transaction=3000000  //需要上面参数为 true
   deliver2store.logminer.only_fetch_archived_log=true  //只解析归档
   deliver2store.logminer.enable_flashback_query=false
   deliver2store.parallelism=32
   

OMS 参数经验值：

实践案例

本节介绍如何将数据从 Oracle 迁移至 OceanBase 数据库。Oracle 源端总共有 15 张表分区表，22 亿条记录需要迁移到 OceanBase 目标端。未优化前，全量迁移耗时 11 小时，平均每秒 5.5w 条记录，速度太慢，不符合客户目标。

1. 优化 OMS。

   -- OMS 参数调整，增大并发
   ## 读线程
   source.workerNum: 并发度和机器 CPU 核数量相关，最大可以设置为 CPU*4
   ## 写线程
   sink.workerNum: 并发度和机器 CPU 核数量相关，最大可以设置为 CPU*4
   ## 一个切片查询的批数量
   source.sliceBatchSize: 大表通常设置为 1000
   ## 最大连接数
   source.databaseMaxConnection
   limitator.platform.threads.number  32 --> 64
   limitator.select.batch.max         1200 --> 2400
   limitator.image.insert.batch.max   200  --> 400
   -- 增大链接数
   limitator.datasource.connections.max 50  --> 200
   -- JVM 内存优化
   -server -Xms16g -Xmx16g -Xmn8g -Xss256k --> -server -Xms64g -Xmx64g -Xmn48g -Xss256k
   11
   

   经过上述调整后，Clog 每分钟产生大约 130 个 64MB 日志（约 8.5GB 日志），CPU 使用率达到满载，网络出口流量达到 500MB。因此，目标端 OceanBase 出现了瓶颈。

2. 优化目标端 OceanBase 数据库。

   -- OceanBase 开启日志压缩
   ALTER SYSTEM SET clog_transport_compress_all = 'true';
   ALTER SYSTEM SET clog_transport_compress_func = 'zlib_1.0';
   -- 租户级别日志压缩
   ALTER SYSTEM SET enable_clog_persistence_compress='true';
   -- OceanBase 加大转储线程
   ALTER SYSTEM SET _mini_merge_concurrency=32;
   ALTER SYSTEM SET minor_merge_concurrency=32;
   -- OceanBase 加大合并线程数
   ALTER SYSTEM SET merge_thread_count=64;
   -- OceanBase 写入限流
   ALTER SYSTEM SET writing_throttling_trigger_percentage =80;
   -- 降低转储内存阈值，让 OceanBase 提前转储
   ALTER SYSTEM SET freeze_trigger_percentage=30;
   

   经调整 OceanBase 内核参数后，每分钟 OceanBase 日志量下降到约 20 个，但 CPU 利用率仍然非常高。原因是大分区表 TRUNCATE 操作后带来的 Checksum Task 开销。如果启动了 Checksum Task 维护，而 OMS 尚未开始导入任务，OceanBase 节点的 CPU 能耗将近 50%。

3. 手动清理内部表。

   -- 清理 TRUNCATE 的分区表元数据
   DELETE FROM __all_sstable_checksum WHERE sstable_id IN 
   (SELECT table_id FROM __all_virtual_table_history WHERE table_name='table_namexxx' minus 
   SELECT table_id FROM __all_virtual_table WHERE table_name='table_namexxx');
   -- 租户 Leader 打散到三个 Zone
   ALTER TENANT tenant_name SET primary zone='RANDOM';
   

   通过调整 OceanBase 部署架构，借助多点写入能力提升性能，OMS 迁移速度提升到大约 7w/s，全量迁移减少到 7 个小时左右完成。

4. 分析慢 SQL。

   SELECT * FROM gv_plan_cache_plan_explain WHERE ip=xxx.xx.xx.x AND port=2882 AND plan_id=160334 AND tenant_id=1004;
   

   优化方法：将分区表改为非分区表。根据历史经验，单表数据不超过 10 亿行或者单表容量不超过 2000GB 可以不考虑分区表。临时删除二级索引，只保留主键，待全量迁移完毕后再建二级索引。

   经过以上 Schema 表结构的优化，并将分区表改造成非分区表以及后建索引，OMS 在 3 个小时内完成全量数据迁移，减少了数据迁移时间。