MySQL Mycat 分布式架构_随笔

参考： https://www.jianshu.com/p/5e0062f6cf62

图中是两组分片，红色我们称为shard1，蓝色我们称为shard2

51 52是服务器

两个3307互为主从(双主)，3309是本地3307的从库

说明：没有明确说明是只在某一个节点上做的，就是两个节点都做

两台虚拟机 db01 db02

每台创建四个mysql实例：3307 3308 3309 3310

mysql软件我们之前已完成二进制安装，直接初始化即可

我们server-id规划为：db01上是7/8/9/10,db02上是17/18/19/20

"箭头指向谁是主库"

10.0.0.51:3307<-----> 10.0.0.52:3307

10.0.0.51:3309------> 10.0.0.51:3307

10.0.0.52:3309------> 10.0.0.52:3307

两个分片，每个分片四个mysql节点

shard1：

Master：10.0.0.51:3307

slave1：10.0.0.51:3309

Standby Master：10.0.0.52:3307

slave2：10.0.0.52:3309

shard2：

Master：10.0.0.52:3308

slave1：10.0.0.52:3310

Standby Master：10.0.0.51:3308

slave2：10.0.0.51:3310

shard1

10.0.0.51:3307 <----->10.0.0.52:3307

db02

db01

db02

10.0.0.51:3309 ------>10.0.0.51:3307

db01

10.0.0.52:3309 ------>10.0.0.52:3307

db02

shard2

10.0.0.52:3308 <----->10.0.0.51:3308

db01

db02

db01

10.0.0.52:3310 ----->10.0.0.52:3308

db02

10.0.0.51:3310 ----->10.0.0.51:3308

db01

这个复制用户在谁上建都行

注：如果中间出现错误，在每个节点进行执行以下命令

常见方案：

360 Atlas-Sharding 360

Alibaba cobar 阿里

Mycat 开源

TDDL 淘宝

Heisenberg 百度

Oceanus 58同城

Vitess 谷歌

OneProxy

DRDS 阿里云

我们装的是openjdk，不是官方的那个

Mycat-server-xxxxx.linux.tar.gz

http://dl.mycat.io/

配置环境变量

我们mycat的命令也是在bin目录下

启动

8066就是对外提供服务的端口，9066是管理端口

连接mycat：

默认123456

db01:

我们一般先把原schema.xml备份，然后自己新写一个：

xml和html看起来差不多，xml是从下往上调用的

前三行我们不用看，直接从第四行schema开始看起：

定义了schema，然后以/schema结尾

为什么要用逻辑库？

业务透明化

此配置文件就是实现读写分离的配置

重启mycat

读写分离测试

总结：

以上案例实现了1主1从的读写分离功能，写 *** 作落到主库，读 *** 作落到从库.如果主库宕机，从库不能在继续提供服务了。

我们推荐这种架构

一写三读，

不设置双写的原因是：性能没提升多少，反而引起主键冲突的情况

配置文件：

之后重启：mycat restart

真正的 writehost：负责写 *** 作的writehost

standby writeHost ：和readhost一样，只提供读服务

我们此处写了两个writehost，默认使用第一个

当写节点宕机后，后面跟的readhost也不提供服务，这时候standby的writehost就提供写服务，

后面跟的readhost提供读服务

测试：

读写分离测试

对db01 3307节点进行关闭和启动,测试读写 *** 作

结果应为另一台(52)的3307(17)是写，3309(19)是读

一旦7号节点恢复，此时因为7落后了，写节点仍是17

balance属性

负载均衡类型，目前的取值有3种：

writeType属性

负载均衡类型，目前的取值有2种：

switchType属性

-1 表示不自动切换

1 默认值，自动切换

2 基于MySQL主从同步的状态决定是否切换，心跳语句为 show slave status

datahost其他配置

maxCon="1000"：最大的并发连接数

minCon="10" ：mycat在启动之后，会在后端节点上自动开启的连接线程，长连接，好处是连接速度快，弊端是占内存

tempReadHostAvailable="1"

这个一主一从时（1个writehost，1个readhost时），可以开启这个参数，如果2个writehost，2个readhost时

<heartbeat>select user()</heartbeat> 监测心跳

其他参数sqlMaxLimit自动分页,必须在启用分表的情况下才生效

创建测试库和表:

我们重启mycat后连接到8066

发现跟一个库一样，实际上已经分到不同的物理硬件上了

分片：对一个"bigtable"，比如说t3表

热点数据表核心表

(1)行数非常多，800w下坡

(2)访问非常频繁

分片的目的：

（1）将大数据量进行分布存储

（2）提供均衡的访问路由

分片策略：

范围 range 800w 1-400w 400w01-800w 不适用于业务访问不均匀的情况

取模 mod(取余数) 和节点的数量进行取模

枚举按枚举的种类分，如移动项目按省份分

哈希 hash

时间流水

优化关联查询（否则join的表在不同分片上，效率会比单库还要低）

全局表

ER分片

案例：移动统一：先拆出边缘业务，再按地域分片，但对应用来说是统一的

vim rule.xml

<rule>

</rule>

<function name="rang-long"

class="io.mycat.route.function.AutoPartitionByLong">

<property name="mapFile">autopartition-long.txt</property>

</function>

===================================

vim autopartition-long.txt

0-10=0

11-20=1

创建测试表：

mysql -S /data/3307/mysql.sock -e "use taobaocreate table t3 (id int not null primary key auto_increment,name varchar(20) not null)"

mysql -S /data/3308/mysql.sock -e "use taobaocreate table t3 (id int not null primary key auto_increment,name varchar(20) not null)"

测试：

重启mycat

mycat restart

mysql -uroot -p123456 -h 127.0.0.1 -P 8066

insert into t3(id,name) values(1,'a')

insert into t3(id,name) values(2,'b')

insert into t3(id,name) values(3,'c')

insert into t3(id,name) values(4,'d')

insert into t3(id,name) values(11,'aa')

insert into t3(id,name) values(12,'bb')

insert into t3(id,name) values(13,'cc')

insert into t3(id,name) values(14,'dd')

取余分片方式：分片键（一个列）与节点数量进行取余，得到余数，将数据写入对应节点

vim schema.xml

vim rule.xml

准备测试环境

创建测试表：

mysql -S /data/3307/mysql.sock -e "use taobaocreate table t4 (id int not null primary key auto_increment,name varchar(20) not null)"

mysql -S /data/3308/mysql.sock -e "use taobaocreate table t4 (id int not null primary key auto_increment,name varchar(20) not null)"

重启mycat

mycat restart

测试：

mysql -uroot -p123456 -h10.0.0.52 -P8066

use TESTDB

insert into t4(id,name) values(1,'a')

insert into t4(id,name) values(2,'b')

insert into t4(id,name) values(3,'c')

insert into t4(id,name) values(4,'d')

分别登录后端节点查询数据

mysql -S /data/3307/mysql.sock

use taobao

select * from t4

mysql -S /data/3308/mysql.sock

use taobao

select * from t4

t5 表

id name telnum

1 bj 1212

2 sh 22222

3 bj 3333

4 sh 44444

5 bj 5555

sharding-by-intfile

vim schema.xml

vim rule.xml

</rule>

</tableRule>

<property name="mapFile">partition-hash-int.txt</property>

</function>

partition-hash-int.txt 配置：

bj=0

sh=1

DEFAULT_NODE=1

columns 标识将要分片的表字段，algorithm 分片函数，其中分片函数配置中，mapFile标识配置文件名称

准备测试环境

mysql -S /data/3307/mysql.sock -e "use taobaocreate table t5 (id int not null primary key auto_increment,name varchar(20) not null)"

mysql -S /data/3308/mysql.sock -e "use taobaocreate table t5 (id int not null primary key auto_increment,name varchar(20) not null)"

重启mycat

mycat restart

mysql -uroot -p123456 -h10.0.0.51 -P8066

use TESTDB

insert into t5(id,name) values(1,'bj')

insert into t5(id,name) values(2,'sh')

insert into t5(id,name) values(3,'bj')

insert into t5(id,name) values(4,'sh')

insert into t5(id,name) values(5,'tj')

a b c d

join

select t1.name ,t.x from t1

join t

select t2.name ,t.x from t2

join t

select t3.name ,t.x from t3

join t

使用场景：

如果你的业务中有些数据类似于数据字典，比如配置文件的配置，

常用业务的配置或者数据量不大很少变动的表，这些表往往不是特别大，

而且大部分的业务场景都会用到，那么这种表适合于Mycat全局表，无须对数据进行切分，

要在所有的分片上保存一份数据即可，Mycat 在Join *** 作中，业务表与全局表进行Join聚合会优先选择相同分片内的全局表join，

避免跨库Join，在进行数据插入 *** 作时，mycat将把数据分发到全局表对应的所有分片执行，在进行数据读取时候将会随机获取一个节点读取数据。

vim schema.xml

后端数据准备

mysql -S /data/3307/mysql.sock

use taobao

create table t_area (id int not null primary key auto_increment,name varchar(20) not null)

mysql -S /data/3308/mysql.sock

use taobao

create table t_area (id int not null primary key auto_increment,name varchar(20) not null)

重启mycat

mycat restart

测试：

mysql -uroot -p123456 -h10.0.0.52 -P8066

use TESTDB

insert into t_area(id,name) values(1,'a')

insert into t_area(id,name) values(2,'b')

insert into t_area(id,name) values(3,'c')

insert into t_area(id,name) values(4,'d')

join

为了防止跨分片join，可以使用E-R模式

A join B

on a.xx=b.yy

join C

on A.id=C.id

</table>

MySQL的cluster方案有很多官方和第三方的选择，选择多就是一种烦恼，因此，我们考虑MySQL数据库满足下三点需求，考察市面上可行的解决方案：

高可用性：主服务器故障后可自动切换到后备服务器可伸缩性：可方便通过脚本增加DB服务器负载均衡：支持手动把某公司的数据请求切换到另外的服务器，可配置哪些公司的数据服务访问哪个服务器

需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点

业务表tb_image部分数据如下所示，其中id唯一，image_no不唯一。image_no表示每个文件的编号，每个文件在业务系统中会生成若干个文件，每个文件的唯一ID就是字段id：

业务表tb_image的一些情况如下：

根据上面对业务的分析，分库分表完全没有必要。单库分表的话，由于要根据image_no和id查询，所以，一种方案是冗余分表（即一份数据以image_no为分片键保存，另一份数据以id为分片键保存）；另一种方案是只以image_no为分片键，而基于id的查询需求，业务层进行结果归并或者引入第三方中间件。

考虑到单库分表比较复杂，所以决定使用分区特性，而且容量评估分区表方案128个分区（每个分区数据量kw级别）完全能保证业务至少稳定运行15年（图中橙色部分是比较贴合自身业务实际增长情况）：

另外，由于RANGE, LIST, HASH分区都不支持VARCHAR列，所以决定采用KEY分区，官方介绍它的原理是以MySQL内置hash算法然后对分区数取模。

选定分片键为image_no，并且决定分区数为128后，就要灌入数据进行可行性和性能测试了。分区数选择128的原因是：11亿/1kw=110≈128，另外程序员情节，喜欢用2的N次方，你懂的。然而， 这个分区数128就是一切噩梦的开始 。

我尝试先插入10w数据到128个分区中，插入后，让我惊讶的现象出现了： 所有奇数编号分区（p1, p3, p5, ... , p2n-1）中居然没有一条数据 ，同时，任何一个偶数编号分区却有很多的数据，而且还不是很均匀。如下图所示：

说明：奇数编号分区的ibd文件大小都是112k，这是创建分区表时初始化大小，实际并没有任何数据。我们可以通过SQL： select partition_name, partition_expression, table_rows from information_schema.partitions where table_schema = schema() and table_name='image_subpart'验证，其部分结果如下图所示：

难道10w条数据还不够说明问题？平均下来每个分区可是有近800条数据！好吧，来点猛的：我再插入990w条数据，总计1kw数据。结果还是一样，奇数编号分区没有数据，偶数编号都有分区。

我们再来回想一下KEY分区的原理： 通过MySQL内置hash算法对分片键计算hash值后再对分区数取模 。这个原理也可以从MySQL官网找到，请戳链接： 22.2.5 KEY Partitioning: https://dev.mysql.com/doc/refman/5.7/en/partitioning-key.html ，截取原文如下：

这个世界上不会有这么渣渣的hash算法吧？ 随便写个什么算法也不至于这么不均匀吧？这时候我怀疑是否有一些什么配置引起的。但是 show variables 中并没有任何与partition相关的变量。

这个时候，一万匹马奔腾而过。会不会是文档和源码不同步导致的？好吧，看MySQL的源码，毕竟， 源码才是最接近真相的地方 。KEY分区相关源码在文件 sql_partition.cc 中，笔者截取部分关键源码，如下所示，初略观察，并没有什么不妥，先计算分区字段的hash值然后对分区数取模：

怀着绝望的心情，请出搜索引擎搜索："KEY分区数据不均匀"，搜索结果中的CSDN论坛（ https://bbs.csdn.net/topics/390857704 ）里有个民间高手 华夏小卒 回答如下：

这个时候，又是一万匹马奔腾而过。不过F**K的同时，心里也是有点小激动，因为可能找到解决办法了（虽然还不知道MySQL内置hash算法为毛会这样），最后笔者再次对KEY分区测试并总结如下：

如下图所示，是笔者把分区数调整为127并插入100w数据后的情况，通过SQL证明每个分区的数据量几乎一样：

MySQL的KEY分区这么大的使用陷阱，居然在官方上没有任何说明，这让笔者感到非常震惊。笔者还尝试Google搜索 mysql partition key uneven ，也有很多结果，例如 stackoverflow：https://stackoverflow.com/questions/38454354/mysql-uneven-distribution-of-data-into-partitions-when-using-key-partitioning ，此外还有MySQL bug： Bug #72428 Partition by KEY() results in uneven data distribution

正在看此文并有很强烈兴趣的同学，可以尝试更深入这个问题。笔者接下来也会找个时间，根据MySQL源码深入挖掘其hash算法的实现为什么对分区数如此敏感。

欢迎分享，转载请注明来源：内存溢出

原文地址: https://outofmemory.cn/zaji/8652996.html

MySQL Mycat 分布式架构

发表评论

评论列表（0条）