国际计费系统基于Sharding-Proxy大数据迁移方案实践

1 背景 

• 计费数据量剧增，需要将老库进行数据拆分到多个分库，数据分片；
• 拆分规则为收付款对象（或 ID）字段，进行 HASH，取模 (32)，分 32 个库

2 目标

• 实现数据从老库，按照分片规则，迁移到分库中
• 保证数据平滑迁移，尽量停产时间最小
• 支持回滚，同步失败，支持回滚单库

3 方案

3.1 基于蜂巢中间件实现

3.2 半自研同步数据处理程序

1. 开发数据处理程序，消费历史数据 MQ；消费增量数据 MQ
2. 基于 dts 同步历史数据（指定时间位点，同步历史）
3. 基于 JDQ 同步实时数据（指定时间位点，恢复实时同步）

3.3 基于开源中间件策略

3.4 完全自研数据处理工具

1. 开发数据查询程序，历史数据查询发送 MQ 写入
2. 实时数据双写
3. 统一发送 MQ，由 MQ 异步处理写入

3.5 方案对比

综上整体评估，我们最终选取，基于 sharding-proxy 做数据迁移整体方案

4 Proxy 介绍与搭建

4.1 简介

4.1.1 设计意义

定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据，对 DBA 更加友好。

• 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用；
• 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。

4.1.2 整体架构

整个架构可以分为前端、后端和核心组件三部分。

前端负责与客户端进行网络通信，采用的是基于 NIO 的客户端 / 服务器框架，在 Windows 和 Mac 操作系统下采用 NIO 模型，Linux 系统自动适配为 Epoll 模型。通信的过程中完成对 MySQL 协议的编解码。核心组件得到解码的 MySQL 命令后，开始调用 Sharding-Core 对 SQL 进行解析、路由、改写、结果归并等核心功能。后端与真实数据库的交互目前借助于 Hikari 连接池。

4.2 搭建

4.2.1 关键字解读

下载，解压，安装 mysql 驱动，启动，完事

4.2.2 安装 shareding-proxy

安装包下载，选择合适版本（本文选用 4.1.1），在官网进行下载，官网地址 https://shardingsphere.apache.org/document/current/cn/downloads

• 安装包解压（自动解压，或是命令解压），解压目录自己随意指定（有权限目录均可）

• 解压后 shareding-proxy 目录

• shareding-proxy 配置目录 conf，包含所有配置数据

4.2.3 安装 mysql 驱动

将 mysql 的驱动 jar 包 (mysql-connector-java-5.1.44.jar) 放在 shareding-proxy 的 lib 目录下 ShardingSphere-Proxy 不带 mysql 驱动 jar 包，需要手动下载
下载地址 https://dev.mysql.com/downloads/connector/j/

4.2.4 proxy 启动

shareding-proxy 的 bin 目录 start.sh，通过./start.sh 启动

4.2.5 Remark

Sharding-Proxy 默认的启动端口是 3307

4.3 配置

4.3.1 关键字解读

六大配置 —— 日志配置 (logback.xml)，基础服务配置 (server.yaml)，逻辑配置 (四个 conf 配置文件，分片（核心）/ 影子 / 读写分离 / 加密配置)
本例基于 server.yaml、config-sharding.yaml 配置分片策略

4.3.2 server.yaml

基础服务配置，三部分组成

1）shareding-jdbc 的编排治理配置，提供数据治理功能，包含如下：

• 配置集中化与动态化。（支持数据源，表与分片读写分离策略的动态切换）
• 数据治理。提供熔断数据库访问程序对数据库的访问和禁用从库的访问的能力
• 支持 Zookeeper 和 etcd 的注册中心；

2）权限配置，配置用户名和密码以及授权数据库

• 下例配置两个用户，分别为：root/root 和 sharding/sharding，其中 root 默认授权所有的数据库，而 sharding 用户则授权 sharding_db 数据库。在这里的数据库（schema）是逻辑数据库，在 config-*.yaml 中配置对应分库映射

• 代理数据源参数配置

配置数据链接，线程，核数等

4.3.3 config-sharding.yaml

shareding-proxy 核心配置，分片规则相关配置，包含 schemaName、dataSources、shardingRule 三部分

1）下图逻辑库对应分库数据源的映射配置

• schemaName 逻辑库名，在 server.yaml 声明的授权的 schema 就是这里的 schemaName
• dataSources 为数据源配置，本例映射俩个分库（ds0，ds_1），ds${0..1} 对应逻辑分库名，url 填写实际库

4.3.4 logback.xml

基于 logback 的日志配置

4.3.5 剩余三项配置

config-shadow.yaml/config-master_slave.yaml/config-encrypt.yaml
分别为影子库配置，主从配置，数据字段加密配置，有意可以自行看下文链接

5 调试

基于搭建 ShardingSphere-Proxy 代理选择直连工具客户端

1. 用 Navicat 或者 mysql 命令直连
2. 手动 mysql 命令链接如下

查询不带拆分键默认搜全库，新增默认根据拆分键路由对应真实库

6 数据迁移

迁移三步

1）线上安装 sharding-proxy
2）数据同步：创建迁移任务，启动同步，原理即是创建 DTS 任务

3）数据完整性校验

• 全量比对，整体同步进度查询

• 时间分段比对，按照各个时间段抽样进行新库老库总量比对，手动校验

• 随机抽样比对：随机新库某个时间段的数据逐条进行比对，手动工具校验
  手动根据开发工具分别抽样查询，并查询出的数据与老库进行比对
• 全量数据校验：对比同步数据进行全量数据校验，根据 DTS 工具进行校验，耗时较长

7 配置查询机

基于 easyops 或者 myops 配置物流指定查询机，通过查询机查询 proxy 代理实现

8 问题与总结

整体数据迁移过程中遇到的最大的问题即是数据不可测，针对各种历史数据问题导致数据迁移中断，造成返工，清理垃圾数据，重新迁移

8.1 拆分键为空

拆分键为空默认不支持

8.2 更新拆分键

更新语句默认不支持更新拆分键 (实际 4.x 不支持更新带拆分键，5.x 已经支持更新带拆分键不改的情况下)
Unknown exception: [INSERT INTO …. ON DUPLICATE KEY UPDATE can not support update for sharding column.]

8.3 针对以上俩种异常的解决方法

拆分键不能为空，设置默认拆分键
更新带拆分键，升级 sharding-proxy 到 5.x 或配置同步 DTS 去掉拆分键更新

作者：任洪波