---

---

上一篇我们一起做了迁移准备与实施规划，接下来我们就来进行数据迁移与系统优化

数据迁移策略：离线与在线方案选型

选择数据迁移方案时，咱们得先看看业务能承受多长时间的停机、数据量有多大，还有对实时性的要求。要是评估下来发现业务能停个半天以上，比如超过8小时，那直接走离线迁移就挺合适。但要是停机时间卡得特别紧，比如不能超过两小时，那就得考虑在线迁移了，这样业务基本不会察觉到切换过程。这两种方式都用到了金仓数据库的工具——离线迁移直接用KDTS搞定全量数据就行，而在线迁移则需要KDTS和KFS配合着来，一个处理历史数据，一个实时同步增量日志，衔接起来特别顺畅。

离线迁移方案

要事遇到那种允许暂停服务的场景，用KDTS工具就能把MySQL数据顺利转到KingbaseES。这个工具挺实用的，不光能迁移表结构和全部数据，还能自定义字段对应关系，甚至通过设置WHERE条件来筛选需要的数据——对于业务比较复杂的情况特别管用。操作的时候记得先把写入服务停掉，等源数据库完全静止了再开始迁移，这样就不会漏掉任何新增的数据了。

在线迁移全流程

线上数据迁移这事儿、其实主要分三步走：先把旧数据搬过去、接着实时抓取新增的数据变动、最后还得核对两边信息是不是完全对得上。

• KDTS 迁移历史数据
  上次用KDTS工具做数据迁移，直接通过命令行配置源端和目标端的连接参数就行。比如之前处理过一个政务系统的活儿，要把2.1TB的历史证照数据全部搬过去，当时用的主要命令大概是这样的：

   kdts -s mysql://username:password@src_host:3306/dbname -t kingbase://username:password@target_host:5432/dbname -m online --verify

直接敲这个命令就能切换到在线模式，加上-m online参数就行。对了，别忘了带上–verify选项，它能把数据一致性检查也一并打开。这样迁移历史数据的时候心里就踏实多了，基本不会出什么岔子。

• KFS 捕获增量日志
  迁移工作都处理好了之后、咱们直接用KFS工具实时抓取MySQL的增量日志、然后同步到KingbaseES里。这个工具用起来挺顺手的、能轻松搞定不同数据源之间的同步问题、比如把MySQL 5或者8版本的数据搬到KingbaseES V9。下面有个配置文件的例子、可以拿来参考一下：

   [source]
   type = mysql
   host = src_host
   port = 3306
   user = username
   password = password
   database = dbname
   binlog_position = latest

   [target]
   type = kingbase
   host = target_host
   port = 5432
   user = username
   password = password
   database = dbname

   [sync]
   mode = incremental
   tables = order_table, user_table

• 数据一致性校验
  迁移完数据后、咱们最好用MD5校验脚本查查文件有没有问题。我这儿刚好有个现成的脚本、可以拿来参考一下：

   # 生成源端数据 MD5
   mysql -u root -p -e "SELECT MD5(CONCAT(col1, col2, col3)) FROM order_table;" > src_md5.txt

   # 生成目标端数据 MD5
   isql -U username -d dbname -c "SELECT MD5(CONCAT(col1, col2, col3)) FROM order_table;" > target_md5.txt

   # 比对结果
   diff src_md5.txt target_md5.txt

实战优化案例：100GB 订单表迁移

咱们来聊聊那次100GB订单表迁移的事儿吧，说实话这事儿挺有意思的。当时的情况是这样的，我们要把整整100GB的订单数据从一个系统搬到另一个系统，这可不是件轻松活儿。我记得那会儿团队里的人都挺紧张的，毕竟这么大的数据量，稍有不慎就可能出岔子。不过最后我们还是顺利搞定了，整个过程虽然费了不少功夫，但收获也挺多的。

上次帮一家装备制造厂搞数据迁移、他们有个100GB的订单表要挪地方。原本估计得花12个小时、后来我们琢磨出个办法——按时间分区分批处理、同时开几个通道一起搬。这么一来、迁移时间直接缩短到3小时。具体操作是这样的：

• 按时间分区拆分大表
  咱们在MySQL里搞个时间分区表、直接拿订单的创建时间来切分数据就行：

   ALTER TABLE orders
   PARTITION BY RANGE (TO_DAYS(create_time)) (
       PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
       PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01')),
       ...
       PARTITION p202312 VALUES LESS THAN (TO_DAYS('2024-01-01'))
   );

• 并行迁移配置
  用KDTS工具搞多线程并行迁移的时候，得把配置文件里这几个重要参数给调好：

   [migration]
   parallel_tasks = 8  # 并行任务数
   batch_size = 10000   # 每批次记录数

关键注意事项

在线迁移核心原则：必须在业务低峰期执行切换，避免增量同步延迟导致的数据不一致。之前做过的一个装备制造企业通过双轨并行运行两周验证数据一致性，最终在周末维护窗口内完成 DNS 切换，实际停机时间<30分钟。

迁移这事儿吧，咱们最好按“数据库和用户→数据→应用”这个顺序来，一步一个脚印地走。要是跳着来，权限设置和数据依赖关系很容易就乱成一团糟了。特别是遇到那种数据量特别大的情况，比如TB级别的，可以考虑用断点续传分批处理的方式，这样操作起来心里更有底。

数据一致性校验与故障恢复

把MySQL的数据搬到KingbaseES这事儿、数据核对这块儿可得上点心。我们之前做项目就发现、最好搞个多层次的检查机制、从不同角度验证才能确保迁移后的数据既准确又完整、还不耽误业务正常开展。实际操作起来可以从这几个方面着手：先核对基础数据对不对得上、再验证业务逻辑有没有跑偏、最后评估下性能表现怎么样。这样一套组合拳打下来、基本就能把数据质量把控得比较到位了。

三层校验体系的构建与实践

1. 基础校验

基础校验主要检查数据是否完整准确、常用的方法就是核对行数和MD5值。行数比对很简单、就是看看源数据库和目标库里的表记录数量有没有明显出入；MD5校验呢、则是把关键字段（比如主键和重要业务字段）做哈希计算、确保每条记录的内容都完全一致。要是遇到LOB类型的大文件数据、比如超过10GB的那种、就得用专门的优化方案来处理了、不然数据加载太慢会影响校验效率。下面这个基础校验脚本示例能自动完成跨库数据比对：

-- MySQL 端生成校验数据
SELECT CONCAT(table_name, ',', COUNT(*), ',', MD5(GROUP_CONCAT(CONCAT_WS(',', id, biz_code) ORDER BY id)))
FROM information_schema.tables
WHERE table_schema = 'target_db'
GROUP BY table_name;

-- KingbaseES 端执行相同逻辑并比对结果

2. 业务校验

业务校验其实就是模拟真实业务场景，看看数据之间的逻辑关系是否合理。比如电商系统里，订单金额和支付金额得对得上，不能这边显示买了100块的东西，那边只付了80块。金融系统更讲究，账户余额和交易流水必须借贷平衡，一分钱都不能差。之前我们帮一家装备制造企业做系统迁移时，就让他们新旧两套系统同时跑了两周，每天核对两边数据是否一致，最后才确认核心生产系统的数据是靠谱的。

3. 性能校验

做性能测试的时候，咱们主要得盯着KingbaseES迁移后的查询速度。可以挑几个典型的业务SQL来测，比如那些复杂的报表查询和高频交易接口，跟之前的数据做个对比。最好用同样的硬件和测试数据，特别要关注平均响应时间和95%分位值这些关键指标，这样才能搞清楚新数据库的性能到底行不行。

故障案例分析与恢复策略

最近我们遇到一个挺头疼的情况，KFS系统同步出了问题，结果订单状态全乱了。这事儿说起来挺常见的，但影响可不小，客户那边收到的信息和实际状态完全对不上号。

上次项目迁移时遇到个麻烦事，KingbaseES的数据同步工具KFS在增量同步时有点延迟，结果订单状态没能及时更新到目标库，业务就出问题了。仔细查了查发现，迁移那会儿源库更新特别频繁，KFS没来得及把数据同步到KingbaseES那边，两边数据就对不上了。

解决方案：迁移后双写模式

项目组琢磨出了个办法来解决这个问题，就是迁移完成后先让系统跑24小时的双写模式。具体怎么个双写法呢？咱们来简单说说这个架构设计。

迁移第一天那会儿，我们让业务系统同时在MySQL和KingbaseES两边记录数据。每天定时检查两边的数据差异，发现新增的就用KFS优先补上，省的再折腾全量迁移。等两边数据完全对齐之后，再逐步把业务流量慢慢切到KingbaseES这边。

遇到数据对不上的情况，咱们最好先用KFS补传新增的部分，别急着全部重来。这么一来，原本要花好几个小时才能搞定的事情，现在几分钟就能解决，业务中断的风险也小多了。

迁移结果确认与故障恢复

迁移这事儿搞定之后，咱们得从不同角度好好看看结果到底行不行：

你不如去系统日志里翻翻看，重点查查Error和Info这两个部分，这样就能搞清楚迁移过程中哪些任务出了状况。

打开迁移报告，所有任务批次和处理对象的总数马上就能看到。成功、失败和跳过的数量也都明明白白列出来了，一眼就能看个大概。

有时候SQL脚本创建对象会出问题，系统就会自动把它扔进FailedScript文件夹里。这样一来你就能直接打开修改，修好后再重新运行一遍，整个过程特别方便省事。

这么一折腾，系统立马就能揪出毛病所在，没一会儿工夫就恢复正常了。数据校验这块儿也做得挺靠谱的，基本上不会掉链子。​

迁移后系统测试及问题处理

迁移后的系统测试需要建立完善的验证体系，涵盖功能、性能两个方面，采用系统的测试策略来保障迁移后系统的稳定性和可用性。功能测试应根据核心业务流程设计用例模板，包括数据一致性校验、业务逻辑正确性验证、异常场景处理等重点环节；性能测试要构建多维指标体系，包含平均响应时间、95%响应时间、TPS（每秒事务数）、资源利用率等，通过模拟生产环境的并发压力来检验系统的负载能力。政务系统迁移的实际效果显示，KingbaseES在复杂查询P95延迟（1.2s）、故障恢复时间（<8s）等方面明显优于原MongoDB环境，JMeter压测的结果也表明，在证照查询场景下500并发时平均响应时间为120ms，TPS为4167，比原来的环境提高了35%。

问题排查与故障恢复案例库

根据实际的迁移工作实践，五大典型故障案例涵盖了数据一致性、性能瓶颈、配置兼容等主要场景，每个案例都按照“现象→排查步骤→解决方案→预防措施”的标准化处理流程来执行：

案例一：日期格式转换错误

• 现象：迁移之后插入’0099-09-30’日期时出现报错"ERROR: date/time field value out of range"，原因是MySQL和KingbaseES对公元前日期的处理方式存在差异

• 排查步骤：

  -- 查看当前日期格式配置
  SHOW datestyle;
  -- 检查错误日志定位具体语句
  SELECT * FROM sys_log WHERE message LIKE '%date/time field value out of range%' ORDER BY log_time DESC LIMIT 10;

• 解决方案：修改kingbase.conf配置文件，调整日期格式来支持更广泛的日期范围

  ALTER SYSTEM SET datestyle = 'ISO, YMD';
  -- 应用配置
  SELECT sys_reload_conf();

预防措施：在迁移之前，使用SQL对源数据中的特殊日期进行预处理

  -- 源端数据清洗示例
  UPDATE target_table SET date_column = CASE
    WHEN date_column < '0001-01-01' THEN NULL
    ELSE date_column
  END;

案例二：KFS同步延迟

现象：KingbaseES文件系统（KFS）数据同步延迟超过30分钟，应用读取到了过期的数据。排查步骤：

  # 检查网络带宽使用情况
  iftop -i eth0 -t 5
  # 查询KFS同步日志
  grep "sync delay" /kingbase/data/kfs/log/sync.log | tail -20
  # 查看同步线程状态
  SELECT * FROM sys_stat_activity WHERE application_name = 'kfs_sync';

调整KFS同步线程数、批处理大小：

  -- 增加同步线程数
  ALTER SYSTEM SET kfs_sync_workers = 8;
  -- 调整批量同步大小
  ALTER SYSTEM SET kfs_batch_size = 1024;

预防措施：同步监控告警部署，延迟超过5分钟时触发通知：

  -- 创建延迟监控函数
  CREATE OR REPLACE FUNCTION check_kfs_delay()
  RETURNS void AS $
  BEGIN
    IF (SELECT EXTRACT(EPOCH FROM (NOW() - last_sync_time))/60 FROM kfs_status) > 5 THEN
      RAISE NOTICE 'KFS sync delay exceeds 5 minutes';
      -- 此处可集成告警系统API
    END IF;
  END;
  $ LANGUAGE plpgsql;

案例三：LOB数据迁移内存溢出

现象：使用DataX迁移大于100MB的LOB字段时，出现"Java heap space"错误，迁移任务中断。

  # 查看JVM内存配置
  ps -ef | grep datax | grep -i xmx
  # 分析迁移日志定位大对象
  grep "LOB field" /datax/logs/job/job.log | grep -v "size < 104857600"

解决办法：在DataX配置里设定内存阈值，当超过该阈值时就使用磁盘缓存

  {
    "job": {
      "setting": {
        "speed": {
          "channel": 4
        },
        "errorLimit": {
          "record": 0,
          "percentage": 0.02
        }
      },
      "content": [
        {
          "reader": {
            "name": "mysqlreader",
            "parameter": {
              "username": "root",
              "password": "password",
              "column": ["id", "content"],
              "connection": [
                {
                  "table": ["large_data"],
                  "jdbcUrl": ["jdbc:mysql://127.0.0.1:3306/test"]
                }
              ],
              "lobInMemoryThresholdSize": "128M"  // LOB内存阈值设置
            }
          },
          "writer": {
            "name": "kingbaseeswriter",
            "parameter": {
              // 目标端配置
            }
          }
        }
      ]
    }
  }

预防措施：在迁移之前按照大小对LOB数据进行分类处理，对于大容量对象则使用专用工具kb_lo_import：

  -- KingbaseES端导入外部LOB文件
  SELECT lo_import('/tmp/large_file.dat', 'oid_column');

案例四：应用双写模式数据不一致

现象：系统切换期间，MySQL和KingbaseES使用双写模式，导致两边数据不一致，差异率约为0.3%。排查步骤

  -- 对比两边表数据总量
  -- MySQL端
  SELECT COUNT(*) FROM target_table;
  -- KingbaseES端
  SELECT COUNT(*) FROM target_table;

  -- 查找不一致记录（通过唯一键关联）
  SELECT a.id FROM mysql_db.target_table a
  LEFT JOIN kingbase_db.target_table b ON a.id = b.id
  WHERE b.id IS NULL OR a.update_time != b.update_time;

• 解决方法：使用分布式事务来保证双写的一致性

  // Java代码示例：使用2PC分布式事务
  @Transactional
  public void dualWrite(Data data) {
      try {
          // 开启分布式事务
          TransactionManager tm = new TransactionManager();
          tm.begin();

          // 写入MySQL
          mysqlMapper.insert(data);
          // 写入KingbaseES
          kingbaseMapper.insert(data);

          tm.commit();
      } catch (Exception e) {
          tm.rollback();
          throw new DataConsistencyException("双写失败", e);
      }
  }

预防措施：采用双写校验机制，定期进行数据一致性检查

  -- 创建数据校验存储过程
  CREATE OR REPLACE PROCEDURE validate_data_consistency()
  LANGUAGE plpgsql
  AS $
  DECLARE
    diff_count INT;
  BEGIN
    CREATE TEMP TABLE diff_ids AS
    SELECT a.id FROM mysql_fdw.target_table a
    LEFT JOIN local_db.target_table b ON a.id = b.id
    WHERE b.id IS NULL OR a.row_hash != b.row_hash;

    GET DIAGNOSTICS diff_count = ROW_COUNT;

    IF diff_count > 0 THEN
      RAISE NOTICE '发现 % 条不一致记录', diff_count;
      -- 此处可集成告警系统API
    END IF;
  END;
  $;

案例五：迁移之后查询性能变差

• 现象：复杂报表查询耗时由原来的1.2秒增加到5.8秒，执行计划显示为全表扫描

排查步骤：

  -- 查看当前执行计划
  EXPLAIN ANALYZE SELECT * FROM complex_query_view WHERE report_date = '2025-01-01';

  -- 检查统计信息状态
  SELECT schemaname, tablename, last_analyze
  FROM sys_stat_user_tables
  WHERE tablename = 'large_fact_table';

• 解决方案：重建统计信息并优化索引：

  -- 分析表生成最新统计信息
  ANALYZE VERBOSE large_fact_table;

  -- 创建缺失索引
  CREATE INDEX idx_fact_date ON large_fact_table (report_date) INCLUDE (metric1, metric2);

  -- 优化器参数调整
  ALTER SYSTEM SET random_page_cost = 1.1;
  SELECT sys_reload_conf();

• 预防措施：建立统计信息自动更新机制：

  -- 创建定时任务自动更新统计信息
  CREATE OR REPLACE EVENT update_stats_event
  ON SCHEDULE EVERY 1 DAY STARTS '03:00:00'
  DO
    ANALYZE ALL TABLES;

迁移测试最佳实践：性能测试应采用与生产环境一致的软硬件配置，使用TPCC或JMeter模拟真实负载。KingbaseES提供专用压测工具kbbench，可通过以下命令测试连接性能：

kbbench -c 1000 -t1 -j16 -S -n -U SYSTEM test_db

测试过程中要同时监控sys_stat_activity视图，保证连接数和线程配置相符合。

迁移之后的问题处理要建立标准化的流程，优先用日志查找问题根源，参数调整要按照“测试→灰度发布→全量上线”的顺序执行。对于关键业务系统，建议保留至少7天的回滚窗口，并通过持续的数据校验来保证长期的一致性。

迁移项目的管理与上线保障

MySQL到KingbaseES迁移项目成功的实施需要依靠科学的项目管理体系以及严格的上线保障机制。结合政务系统、装备制造企业等多行业的迁移经验，需要建立覆盖全生命周期的管理框架，以保证迁移过程可控、风险最小化。

迁移项目的整个生命周期的管理

迁移项目实施应按照标准化阶段进行划分，每个阶段都要设置清晰的里程碑来保证项目的进度和质量；

之前做过的一个装备制造企业使用了该框架实现了零停机迁移，采取双轨并行的策略：第一阶段以原MySQL为生产端，KingbaseES作为热备；第二阶段通过DNS切换将100%的流量引导到KingbaseES上；第三阶段在稳定运行72小时后断开反向同步，最后系统响应时间下降80%以上。

上线切换四步曲及风险控制

上线切换是迁移过程中的重要一环，要按照“四步曲”的操作流程来执行，并且要有灰度验证以及应急回滚机制以保障业务的连续性：

• 预切换检查

需要进行数据一致性校验（使用全量+增量比对工具）、应用连通性测试（JDBC驱动适配性验证）以及安全合规性验证。KingbaseES 默认启用 SSL 加密与细粒度审计日志，可以直接满足等保三级要求，相对于 MySQL 需要手动配置审计功能更优。以前做的一个政务项目因为没有设置角色权限而切换失败，也说明了 checklist 检查的重要性——包括账号权限、索引有效性、存储过程兼容性在内的18个必查项都必须检查到。

• 灰度发布

采用流量比例递增的方式，首先将 10% 的非核心业务流量导向 KingbaseES，并且重点监控接口响应时间、错误率以及数据库连接数等指标。之前做过的金融系统用此方法发现热点数据查询性能瓶颈，经过索引优化后平均响应时间由300ms降到了45ms。

• 全量切换

在业务低谷的时候进行切换，切换之后持续监测CPU使用率、锁等待时间、事务吞吐量等重要指标30分钟。政务系统中模拟了1600+并发连接、500ms网络延迟的极端情况来测试全量切换的稳定性。

• 回滚方案

设置预触发条件（比如错误率突然超过0.1%或者响应时间翻倍），用双写机制和数据同步工具在5分钟内快速切换回MySQL。之前做过的一个电商项目由于SQL语法兼容问题触发了回滚，最后通过预切换阶段的SQL审计工具提前规避了类似风险。

• 上线后观察期管理

系统全量切换之后要保证 72 小时的连续观察，并且要关注：

日均调用量的波动情况（政务系统127万次/日）- 异常查询比例（三层嵌套查询导致的性能损失）- 故障自愈能力（主节点宕机后自动切换所用的时间）

经过稳定性验证之后，才可以将原 MySQL 环境下线。

上线之后要观察72小时，保证系统稳定了再下线原来的MySQL环境

之前做过的一个省级政务系统在完成全量切换之后，经过45天的持续监控验证了KingbaseES的生产可用性，混合查询场景下的日均承载量为127万次（包含高频亮证查询和嵌套联合查询），并且在随机故障注入测试中表现出良好的容错能力