Mycat分库分表的简单实践

MySQL的使用场景中，读写分离只是方案中的一部分，想要扩展，势必会用到分库分表，可喜的是Mycat里已经做到了，今天花时间测试了一下，感觉还不错。

成都创新互联专注为客户提供全方位的互联网综合服务，包含不限于网站设计、网站建设、瓮安网络推广、成都小程序开发、瓮安网络营销、瓮安企业策划、瓮安品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；成都创新互联为所有大学生创业者提供瓮安建站搭建服务，24小时服务热线：028-86922220，官方网址：www.cdcxhl.com

关于分库分表

当然自己也理了一下，分库分表的这些内容，如果分成几个策略或者阶段，大概有下面的几种。 Mycat分库分表的简单实践

最上面的第一种是直接拆表，比如数据库db1下面有test1,test2,test3三个表，通过中间件看到的还是表test,里面的数据做了这样的拆分，能够咋一定程度上分解压力，如果细细品来，和分区表的套路有些像。

接下来的几类也是不断完善，把表test拆解到多个库中，多个服务器中，如果做了读写分离，全套的方案这样的拆解改进还是很大的。如此来看，数据库中间件做了很多应用和数据库之间的很多事情，能够流行起来除了技术原因还是有很多其他的因素。

分库分表的测试环境模拟

如果要在一台服务器上测试分库分表，而且要求架构方案要全面，作为技术可行性的一个判定参考，是否可以实现呢。

如果模拟一主两从的架构，模拟服务分布在3台服务器上，这样的方案需要创建9个实例,每个实例上有3个db需要分别拆分。

大体的配置如下：

master1: 端口33091

(m1)slave1: 端口33092

(m1)slave2: 端口33093

master2: 端口33071

(m2)slave1: 端口33072

(m2)slave2: 端口33073

master3: 端口33061

(m3)slave1: 端口33062

(m3)slave2: 端口33063

画个图来说明一下，其中db1,db2,db3下面有若个表，需要做sharding

Mycat分库分表的简单实践

所以我们需要模拟的就是这个事情。

使用Mycat碰到的几个小问题解惑

使用Mycat的时候碰到了几个小问题，感觉比较有代表性，记录了一下。

问题1：

手下是使用Mycat连接到数据库之后，如果不切换到具体的数据库下，使用[数据库名].[表名]的方式会抛出下面的错误，可见整个过程中，Mycat拦截了SQL信息做了过滤，在转换的时候找不到目标路由。当然实际使用中，规范使用肯定不会有这个问题。

mysql> select * from db1.shard_auto;
ERROR 1064 (HY000): find no Route:select * from db1.shard_auto
问题2：
在配置了sharding策略之后，insert语句抛出了下面的错误，这个是对语法的一个基本的要求。
mysql> insert into shard_mod_long values(1,'aa',date);
ERROR 1064 (HY000): partition table, insert must provide ColumnList
问题3：

如果sharding策略配置有误，很可能出现表访问正常，但是DML会有问题，提示数据冲突了。至于如何配置sharding,下面会讲。
mysql> select *from shard_mod_long;
Empty set (0.00 sec)

mysql> insert into shard_mod_long(ID,name,shard_date) values(1,'aa',current_date);
ERROR 1105 (HY000): Duplicate entry '1' for key 'PRIMARY'
问题4：
如果sharding的配置有误，很可能出现多份冗余数据。

查看执行计划就一目了然，通过data_node可以看到数据指向了多个目标库。

mysql> explain insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date);
+-----------+------------------------------------------------+
| DATA_NODE | SQL |
+-----------+------------------------------------------------+
| pxcNode11 | insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date) |
| pxcNode21 | insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date) |
| pxcNode31 | insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date) |
+-----------+------------------------------------------------+

这种情况如果有一定的需求还是蛮不错的，做sharding可惜了。问题就在于下面的这个table配置。

需要去掉 type="global"的属性，让它sharding。

Mycat里面的sharding策略

Mycat的分片策略很丰富，这个是超出自己的预期的，也是Mycat的一大亮点。

大体分片规则如下，另外还有一些其他分片方式这里不全部列举：
（1）分片枚举：sharding-by-intfile
（2）主键范围：auto-sharding-long
（3）一致性hash：sharding-by-murmur
（4）字符串hash解析：sharding-by-stringhash
（5）按日期（天）分片：sharding-by-date
（6）按单月小时拆分：sharding-by-hour
（7）自然月分片：sharding-by-month

在开始之前，我们要创建下面的表来模拟几个sharding的场景,表名根据需求可以改变。
create table shard_test(ID int primary key, name varchar(20),shard_date date);

主键范围分片

主键范围分片是参考了主键值，按照主键值的分布来分布数据库在不同的库中，我们现在对应的sharding节点上创建同样的表结构。

关于sharding的策略，需要修改rule.xml文件。

常用的sharding策略已经在Mycat里面实现了，如果要自行实现也可以定制。比如下面的规则，是基于主键字段ID来做sharding,分布的算法是rang-long,引用了function rang-long,这个function是在对应的一个Java类中实现的。

                        ID
                        rang-long


                        class="io.mycat.route.function.AutoPartitionByLong">
                autopartition-long.txt
当然主键的范围是不固定的，可以根据需求来定制，比如按照一百万为单位，或者1000位单位，文件是 autopartition-long.txt 文件的内容默认如下，模板里是分为了3个分片，如果要定制更多的就需要继续配置了，目前来看这个配置只能够承载15亿的数据量，可以根据需求继续扩展定制。
# range start-end ,data node index
# K=1000,M=10000.
0-500M=0
500M-1000M=1
1000M-1500M=2

插入一些数据来验证一下，我们可以查看执行计划来做基本的验证，配置无误，数据就根据规则流向了指定的数据库下的表里。

还有一个查看sharding效果的小方法，比如我插入一个极大的值，保证和其他数据不在一个分片上，我们运行查询语句两次，结果会有点变化。

sharing的效果
mysql> select *from shard_auto;
+---------+------+------------+
| ID      | name | shard_date |
+---------+------+------------+
|       1 | aa   | 2017-09-06 |
|       2 | bb   | 2017-09-06 |
| 5000001 | aa   | 2017-09-06 |
+---------+------+------------+
3 rows in set (0.00 sec)
稍作停顿，继续运行。
mysql> select *from shard_auto;
+---------+------+------------+
| ID      | name | shard_date |
+---------+------+------------+
| 5000001 | aa   | 2017-09-06 |
|       1 | aa   | 2017-09-06 |
|       2 | bb   | 2017-09-06 |
+---------+------+------------+
3 rows in set (0.01 sec)

Hash分片

Hash分片其实企业级应用尤其广泛，我觉得很的一个原因是通过这种数据路由的方式，得到的数据情况是基本可控的，和业务的关联起来比较直接。很多拆分方法都是根据mod方法来平均分布数据。

sharding的策略在rule.xml里面配置，还是默认的mod-long规则，引用了算法mod-long,这里是根据sharding的节点数来做的，默认是3个。

                        id
                        mod-long





                3

比如查看两次insert的结果情况。

mysql> explain insert into shard_mod_long(ID,name,shard_date) values(4,'dd',current_date);
+-----------+------------------------------------------------+
| DATA_NODE | SQL |
+-----------+------------------------------------------------+
| pxcNode22 | insert into shard_mod_long(ID,name,shard_date) values(4,'dd',current_date) |
+-----------+------------------------------------------------+

mysql> explain insert into shard_mod_long(ID,name,shard_date) values(5,'ee',current_date);
+-----------+------------------------------------------------+
| DATA_NODE | SQL |
+-----------+------------------------------------------------+
| pxcNode23 | insert into shard_mod_long(ID,name,shard_date) values(5,'ee',current_date) |
+-----------+------------------------------------------------+
可以看到数据还是遵循了节点的规律，平均分布。

至于schema.xml的配置，是整个分库的核心，我索性也给出一个配置来，供参考。

                    writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">

            show slave status



                     writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">

            show slave status



                    writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">

            show slave status

新闻标题：Mycat分库分表的简单实践
网站路径：http://kswsj.cn/article/jschso.html

关于创新互联

Mycat分库分表的简单实践

其他资讯