MySQL业务数据分库分表-数据迁移

                                          分库分表

一.项目背景

1. 现有业务数据架构

2.现有资源配置

MySQL业务数据分库分表-数据迁移_第1张图片

 

3.现有业务TPS + QPS统计

A:TPS :峰值:0.27K   

B:QPS:峰值:6K

4. 现有业务量统计

日增

日增索引占用空间

年增

备注

单量

60W

60 * 365=21900W

主表磁盘占用

0.6 G

5G

0.6 * 365 = 200G

二.现有业务遗留问题

1.原订单主表的主键id 参与了第三方系统的业务

A:id 在自身业务系统中没有业务属性,但该值参与了第三方系统的业务并作为了唯一标识。

   这为后续数据迁移带来影响,保证现有业务平滑过度。

 

   解决方案:生成全局唯一的业务id

B:现有订单库中用户id使用Integer类型,长度过短,该值也参与了第三方系统的业务中。

   数据迁移后该值需要升为Long ,迁移导致的类型转换问题。

C:系统底层现有订单库表读权限开放给了第三方业务系统,迁移后改查询权限关闭,订单需提供API暴露给第三方。

   问题:对接第三方查询逻辑

三.迁移数据库资源服务架构设计

1.数据库服务配置

节点

cpu

mem

disk

备注

RW

8c

32g

10T

XXXX * 服务器数量=XXXXX元/每月

RO

8c

32g

10T

2.

MySQL业务数据分库分表-数据迁移_第2张图片

 

3. 现有订单数据库负载信息:

cpu利用率

磁盘使用

接收客户端流量

发送客户端 流量

QPS

TPS

thread_running

平均5%

3608.282G

平均2MB/s

平均10MB/s

最大7000/s 

平均5000/s

最大384/s 平均 250/s

6

4.分库分表策略

4个实例 * 每个实例4个库 * 每个库32张表

4 * 4 * 32 = 512 张表

4.1. 客户端查询的路由键-userId 

A:先根据userId 与4 取模,定位数据库

    再根据userID 与32 取模,定位表number 

B:每个实例

C:分库分表仅适用于带有路由键userID的客户端查询,除此之外的聚合查询( 基于其他业务维度的查询,跨时间的分页查询)均通过nosql-MongoDB的存储介质进行查询。

四.分库分表迁移步骤

1.数据多写

A:写原老库 ,读原老库

B:老库写成功后,同步写新分库;MQ同步给nosql 作为聚合查询数据基础

2.老数据迁移到新库

A:先从新库中的N张表中筛选出最早生成的订单ID,然后在老库中把该订单之前的所有数据同步到新库表。

B:在迁移老数据过程中,新老库都会发生写操作,对于仍未写成功到新库的订单会写失败,所以需要记录在同步老数据过程中所有发生过的写操作,每条流水数据都需要保留时间戳,最后取最新时间戳的订单同步到新库中。

C:迁移过程中写库操作有可能失败,同时也要记录失败的数据落盘存储,并进行数据补偿操作。为最大限度保证落盘成功尽量使用flume 持久化到文件中,当然写到MySQL也可以但仍要考虑失败的情况。

D:校验新老库数据库完整性,准确性。

3.读老库迁移到读新库

A:新老数据对齐后则可以切换读操作的数据源了

4. 写老库为主变成读写新库

你可能感兴趣的:(分布式)