mysql动态分库分表_mysql 分库分表 ~ 总揽分析

一 简介:分库分表的理解

二 具体: 1 当由于单台DB业务增长导致的服务器压力时,就必须横向进行扩展 2 本文仅从中间层观点进行分析

三 现有方案

方案1 sharding家族

Sharding-JDBC是一款轻量级的Java框架，在JDBC层提供上述核心功能，使用方式与正常的JDBC方式如出一辙，面向Java开发的用户。

Sharding-Proxy是一款实现了MySQL二进制协议的服务器端版本，大家可以把它当成升级版的MySQL数据库使用。独立部署后，即可按照正常MySQL操作方式来使用上述所有的核心功能。

设计 在程序端利用设计控制,根据计算出的路由指定数据库节点.

特点 sharding优势

1 程序端进行控制,非常方便.利用代码计算分片字段,控制分片规则.不会产生性能损耗

2 程序能够封装面对不同种类数据库

sharding问题

1 不支持分布式事务,需要利用路由进行事务操作

2 不支持分布式事务,全局DDL需要到每个分片进行执行

3 不支持动态扩容

4 不具有通用性,因为是根据业务进行设计的

过程 通过对片键的换算绝对分片节点,再通过片键的换算定位分表,达到分片分表目的

方案 2 中间件家族

设计 采用开源界的开源中间件进行设计控制,路由规则和分片都配置在中间件,然后指定后端机器

特点 1 开源中间件分为两种

一种是支持分布式事务,比如cetus mycat

一种是不支持分布式事务,比如kingshard

2 开源中间件的优势

1 中间件具有通用性,定义好的分片方法和路由规则,可以应用到多种业务场景

2 中间件大多拥有读写分离特性,可以直接应用

3 开源中间件可能存在的问题

1 中间件本身hang住,导致业务不可用

2 中间件本身发生崩溃或者OOM占用很高,导致业务不可用

3 中间件本身的性能损耗问题,是否可以接受

4 中间件如果上线,程序还是得做一定程度的浅改造

5 中间件本身也不支持动态扩容

6 中间件是否还在开源界维护

7 中间件维护和备份数据等问题

四 存在的普遍问题

1 程序是否采用分布式事务问题

2 全局性DDL操作问题

3 分片集群的查询问题

4 分片集群的扩容问题

5 分片集群的备份数据一致性问题

五 分片集群的普通扩容方案思路

准备条件

1 完全一倍的硬件替换环境

2 需要在分片时准备足够多的桶

3 需要预选准备好新的分片程序

方案

1 按照原集群备份建立相应的最新备份库,并提供账号和备份截止时间给新程序

2 调整原集群binlog保留全部

3 新程序进行消费最新备份数据,根据主键对照原则,新集群插入一条,备份库删除一条,最后原备份库数据全部清空,保证数据的正确过度(类似于pt-archiver)

4 建立canal服务,当新集群消费完毕后,配置指定时间戳进行消费binlog

5 当消费完全后,在业务低峰时期,进行业务切换即可

六 分片集群主键的规划

目的 保证集群本身各个节点的主键不唯一

分类

1 uuid 最原始(不建议用这个),保证唯一

2 业务组合数字串(time+产品ID+用户ID)类似标记唯一,而且还能进行利用

3 通过雪花算法生成(需要时钟校验,否则可能产生冲突)

我们强烈推荐第二种方案,具有业务意义的主键才是我们需要的,我们本身也采用第二种

七 分片集群的查询

1 禁止跨分片的查询,任何分片集群查询都要带上分片条件

2 非实时查询业务

目的 汇总备份并提供查询

1 hbase

2 es+canal

八 总结

1 按照业务角度进行管理划分,不建议采用通用方案

2 预估未来N年的数据量,确定表的字段和索引. 这两项非常重要,如果一旦触发其中一个,操作起来是非常麻烦的