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

                                          分库分表

一．项目背景 1. 现有业务数据架构

2.现有资源配置

 

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.

 

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. 写老库为主变成读写新库