关于数据库:国际计费系统基于ShardingProxy大数据迁移方案实践

37次阅读

共计 2818 个字符,预计需要花费 8 分钟才能阅读完成。

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…

安装包解压(主动解压,或是命令解压),解压目录本人随便指定(有权限目录均可)

解压后 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/downloa…

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 去掉拆分键更新

作者:任洪波

正文完
 0