乐趣区

关于数据库:5分钟搞定-MySQL-到-PolarDBX-数据迁移和同步CloudCanal实战

简述

CloudCanal 近期反对了 PolarDB-X 对端, 目前凋谢的链路为 MySQL 到 PolarDB-X。

本链路特点包含

  • 残缺反对构造迁徙、全量迁徙、增量同步、数据校验
  • 反对 PolarDB-X 云版本 API 级对接(主动获取实例、增加白名单)
  • 反对 PolarDB-X 开源自建版

PolarDB-X 前身 DRDS (外部产品名称 TDDL), 通过 10 几年倒退, 很好解决了 ToC 端业务对数据库超高并发、严苛事务的需要,并且近几年也致力尝试解决企业级数据需要(简单 SQL、分布式事务、在线数据的实时计算),而这样的一个产品,目前有云版本,同时近期也进行了开源。所以咱们认为有必要对其生态做良好撑持。

技术点

构造迁徙

PolarDB-X 是分布式数据库畛域产品,所以存在 partition 概念,提供了两种拆分模型:sharding(即分库分表)和partitioning。前者按用户自定义拆分,后者对利用通明。能够通过相似 create database d1 partition_mode="sharding"create database d1 partition_mode="partitioning" 指定。

sharding模式下,具体创立语句和算法可参考 官网文档

对于响应工夫、RPS 要求的严苛利用场景(绝对较窄), 设定业务感知的分库分表算法是正当的,这也是为何很多分布式数据库在相似 sysbench 或 tpcc 或 天猫双十一 场景中达到难以置信性能的奢侈原理。

CloudCanal 目前主动创立 database 为 sharding 模型,并且通过产品化形式反对这个能力 - 抉择相应的算法和字段。

目前反对分库分表类型包含

  • DB(只分库不分表)
  • DB_TAB(既分库又分表)
  • NONE(单表)

设定分库分表字段的时候,反对的算法包含

  • HASH
  • WEEK
  • MM
  • DD
  • MMDD

一张一般的表,如果利用 DB_TAB 分库分表类型,并且抉择罕用的 HASH 算法,字段都抉择worker_id, 通过 CloudCanal 构造迁徙,会在 PolarDB-X 中生成如下表

CREATE TABLE `worker_stats` (`id` bigint(20) NOT NULL AUTO_INCREMENT BY GROUP,
    `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
    `worker_id` bigint(20) NOT NULL,
    `cpu_stat` text,
    `mem_stat` text,
    `disk_stat` text,
    `col_new` varchar(255) NOT NULL DEFAULT '123',
    PRIMARY KEY (`id`),
    KEY `auto_shard_key_worker_id` USING BTREE (`worker_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 278489 DEFAULT CHARSET = utf8mb4 DEFAULT COLLATE = utf8mb4_0900_ai_ci  dbpartition by hash(`worker_id`) tbpartition by hash(`worker_id`) tbpartitions 4

工作对分库分表的解决

与一般单机数据库不同, 如果须要达到 PolarDB-X 最好的写入性能, 增量同步须要解决分库分表字段, 对于 update 和 delete 操作, 带上拆分字段。数据校验进行对端数据获取时,也须要带上拆分字段,并且保证数据的获取效率。

if (col.isKey() || (partitionKeys != null && partitionKeys.contains(col.getName()))) {if (col.isUpdated()) {
               // put before column in it , PK/UKs may be change.
               pkCols.add(SqlUtilCommon.pickBeforeColumn(rowData, col.getName()));
        } else {pkCols.add(col);
        }

        if (firstPk) {where.append("`").append(col.getName()).append("`= ?");
              firstPk = false;
       } else {where.append("AND `").append(col.getName()).append("`= ?");
        }
}

另外,如同变更主键, 如果变更拆分字段值, 目前 PolarDB-X 可能自行处理这种变动,无需用户本人删除老数据, 插入新数据。

举个例子

前置条件:

  • CloudCanal 社区版部署结束, 参见 CloudCanal 社区版装置文档
  • PolarDB-X 开源版曾经装置, 参见 PolarDB-X 集群部署文档
  • 带有增量流量的 MySQL 运行中

造数据

  • 混合负载,IUD 比例 2:7:1

增加数据源

  • 登录 CloudCanal 平台
  • 数据源治理 -> 新增数据源
  • 别离抉择 自建 部署模式下的 PolarDB-XMySQL 并增加

工作创立

  • 工作治理 -> 工作创立
  • 抉择源和指标数据源
  • 抉择数据同步,并勾选 全量数据初始化, 其余选项默认
  • 抉择须要迁徙同步的表
  • 抉择列, 默认全选
  • 设定分库分表算法和字段
  • 确认创立, 并主动运行

校验工作

  • 进行增量负载
  • 创立校验工作

    • 目前相似工作创立开发中,临时库表列抉择和拆分抉择请和同步工作保持一致
  • 校验结束数据统一

FAQ

是否会反对 PolarDB-X 源端?

目前 PolarDB-X 版本反对 CDC , 和 MySQL binlog 交互很类似(外在体现出些许差异), 咱们将在不久推出 PolarDB-X 源端, 指标端仍首选 MySQL (让业务有去有回)。

是否会反对更多源端?

CloudCanal 新增数据源之后,后续互相买通绝对简略,目前 Oracle 是首选源端。之后 PostgreSQL、SqlServer(开发中)都是候选。

目前这条链路还存在什么有余?

性能层面目前主动创立数据库未反对 PolarDB-X 的 partitioning 模式,另外已存在表,无奈感知对端分库分表字段(急需修复)。性能层面则须要更多调优。

总结

本文简略介绍了应用 CloudCanal 进行 MySQL 到 PolarDB-X 的数据迁徙同步。各位小伙伴,如果感觉还不错,请点赞、评论加转发吧。

更多精彩

  • 异地多活根底之数据双向同步进阶篇 -CloudCanal 实战
  • 5 分钟搞定 MySQL 到 ClickHouse 实时数据同步进阶篇 -CloudCanal 实战
  • 支流关系型数据库到 Kudu 实时数据同步 -CloudCanal 实战
  • 5 分钟搞定 MySQL 到 ElasticSearch 迁徙同步 -CloudCanal 实战
  • 5 分钟搞定 MySQL 到 MySQL 异构在线数据迁徙同步 -CloudCanal 实战
  • MySQL 到 ElasticSearch 实时同步构建数据检索服务的选型与思考
  • 构建基于 Kafka 直达的混合云在线数据生态 -cloudcanal 实战
  • 5 分钟搞定 MySQL 到 TiDB 的数据同步 – CloudCanal 实战

社区快讯

  • 咱们创立 CloudCanal 微信粉丝群啦,在外面,你能够失去最新版本公布信息和资源链接,你能看到其余用户一手评测、应用状况,你更能失去激情的问题解答,当然你还能够给咱们提需要和问题。快快退出吧。

    • 扫描下方二维码,增加咱们小助手微信拉您进群,接头语 (“加 CloudCanal 交换群”)

      退出 CloudCanal 粉丝群把握一手音讯和获取更多福利,请增加咱们小助手微信:suhuayue001
      CloudCanal- 收费好用的企业级数据同步工具,欢送品鉴。
      理解更多产品能够查看官方网站:http://www.clougence.com
      CloudCanal 社区:https://www.askcug.com/
退出移动版