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

原创于 2022-08-09 11:56:30 发布 · 889 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#大数据 #数据库 #postgresql

技术分享同时被 3 个专栏收录

384 篇文章

订阅专栏

数据库

95 篇文章

订阅专栏

数据迁移

13 篇文章

订阅专栏

1 背景

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

2 目标

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

3 方案

3.1 基于蜂巢中间件实现

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

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

3.3 基于开源中间件策略

3.4 完全自研数据处理工具

开发数据查询程序，历史数据查询发送 MQ 写入
实时数据双写
统一发送 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 代理选择直连工具客户端

用 Navicat 或者 mysql 命令直连
手动 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 去掉拆分键更新

作者：任洪波