首页 > 其他分享 > Mycat分片规则与数据分布不一致问题

Mycat分片规则与数据分布不一致问题

时间:2022-11-17 15:57:42浏览次数:46  
标签:mysql Mycat 数据分布 分片 employee 主键 101 id

Mycat作为数据库中间件,本身并不存储数据。Mycat通过其分片规则与读写规则,实现对后端众多mysql数据库实例的分布式访问。但是,在实际使用过程中,可能会出现实际的数据分布与分片规则不一致的情况。譬如: 1. mysql可通过直连方式访问,这就有可能将任意数据写到任意的数据库实例中; 2. Mycat后期调整分片规则时,前期已写入的数据与调整后的分片规则不一致;
当Mycat的分片规则与实际的数据分布不一致时,在执行sql时,有些问题需要注意。下面以一个例子来具体说明。
例子: 1. 建表、配置表分片规则

#建employee表,主键为id字段 CREATE TABLE employee ( id int(11) NOT NULL, name varchar(100) DEFAULT NULL, sharding_id int(11) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
#分片规则,dn00 - dn04 <table name="employee" primaryKey=" ID " autoIncrement="true" dataNode=" dn0$0-3 " rule="employee" />
#分片字段为sharding_id <tableRule name="employee"> <rule> <columns> sharding_id </columns> <algorithm>myfunc1</algorithm> </rule> </tableRule>
#分片规则:根据sharding_id的枚举值分片 0=0 1=1 2=2 3=3
2. 通过直接mysql,分别在dn00和dn03写入数据
insert into employee(id,name,sharding_id) values(101,'dn00',3); --写入dn00 insert into employee(id,name,sharding_id) values(101,'dn03',3); --写入dn03 这里注意2点: 1. id字段均为101,也就是重复主键了。但数据存在mysql不同的实例中,故不会报错。 2. 分片字段sharding_id的值均为3。但实际上这2条记录是存在不同的分片上的。
3. 查询employee,到4个分片上广播查询,没问题。实际查询出来的数据,也是4个分片的数据合集。
mysql> explain select * from employee; +-----------+----------------------------------+ | DATA_NODE | SQL | +-----------+----------------------------------+ | dn00 | SELECT * FROM employee LIMIT 100 | | dn01 | SELECT * FROM employee LIMIT 100 | | dn02 | SELECT * FROM employee LIMIT 100 | | dn03 | SELECT * FROM employee LIMIT 100 | #到每个分片上广播查询 +-----------+----------------------------------+ 4 rows in set (0.01 sec)
mysql> select * from employee; +-----+------+-------------+ | id | name | sharding_id | +-----+------+-------------+ | 101 | dn00 | 3 | | 101 | dn03 | 3 | +-----+------+-------------+ 2 rows in set (0.00 sec)
4. 下面再来看按分片字段查询的情况。从测试结果来看, 若按分片字段查询,Mycat只会通过分片规则到指定的分片上进行查询,即使在其它分片上也有满足where条件的记录。
mysql> explain select * from employee where sharding_id=3; +-----------+--------------------------------------------------------+ | DATA_NODE | SQL | +-----------+--------------------------------------------------------+ | dn03 | SELECT * FROM employee WHERE sharding_id = 3 LIMIT 100 | #根据分片规则到指定分片查询 +-----------+--------------------------------------------------------+ 1 row in set (0.04 sec)
mysql> select * from employee where sharding_id=3; +-----+------+-------------+ | id | name | sharding_id | +-----+------+-------------+ | 101 | dn03 | 3 | +-----+------+-------------+ 1 row in set (0.00 sec)
5. 按主键查询。先来看第一次按主键查询的情况,可以看到,第一次按主键(id=101)查询,由于主键(到分片)缓存并未命中该主键值,Mycat会到每个分片进行广播查询。故查询结果为所有分片的查询结果合集。
mysql> explain select * from employee where id=101; +-----------+-------------------------------------+ | DATA_NODE | SQL | +-----------+-------------------------------------+ | dn00 | select * from employee where id=101 | | dn01 | select * from employee where id=101 | | dn02 | select * from employee where id=101 | | dn03 | select * from employee where id=101 | +-----------+-------------------------------------+ 4 rows in set (0.00 sec)
mysql> select * from employee where id=101; +-----+------+-------------+ | id | name | sharding_id | +-----+------+-------------+ | 101 | dn00 | 3 | | 101 | dn03 | 3 | +-----+------+-------------+ 2 rows in set (0.00 sec)
6. 再来看第二次按主键(id=101)查询的情况,此时,由于Mycat已对该主键作了主键(到分片)缓存,故Mycat无须到每个分片上进行广播查询。 但是,由于每一次查询时,有2条记录返回,而Mycat只会对第1条记录的主键和分片作缓存处理。所以当再次查询时,Mycat从缓存命中的是这一条记录的分片。 另外,从例子可看到,从缓存中命中到的记录,其实它的实际分片位置与分片规则是不一致的。
mysql> show @@cache; +---------------------------------------+-------+------+--------+------+------+---------------+---------------+ | CACHE | MAX | CUR | ACCESS | HIT | PUT | LAST_ACCESS | LAST_PUT | +---------------------------------------+-------+------+--------+------+------+---------------+---------------+ | ER_SQL2PARENTID | 1000 | 0 | 0 | 0 | 0 | 0 | 0 | | SQLRouteCache | 10000 | 2 | 13 | 7 | 2 | 1513329652279 | 1513328908328 | | TableID2DataNodeCache.TESTDB_ORDERS | 50000 | 0 | 0 | 0 | 0 | 0 | 0 | | TableID2DataNodeCache.TESTDB_EMPLOYEE | 10000 | 1 | 4 | 2 | 1 | 1513329652280 | 1513329310256 | +---------------------------------------+-------+------+--------+------+------+---------------+---------------+ 4 rows in set (0.01 sec)
mysql> explain select * from employee where id=101; +-----------+-------------------------------------+ | DATA_NODE | SQL | +-----------+-------------------------------------+ | dn00 | select * from employee where id=101 | #只到所缓存的一个分片上进行查询 +-----------+-------------------------------------+ 1 row in set (0.00 sec)
mysql> select * from employee where id=101; +-----+------+-------------+ | id | name | sharding_id | +-----+------+-------------+ | 101 | dn00 | 3 | +-----+------+-------------+ 1 row in set (0.00 sec)
7. 下面再来看按主键删除记录: (1)由于主键缓存命中到该主键,故只删除了主键缓存指向分片的记录(另一条记录仍存在); (2)删除后,主键缓存中并未删除该主键值的缓存,故再按主键查询时,并无记录返回(缓存所指向的分片已无该主键记录)。
mysql> delete from employee where id=101; Query OK, 1 row affected (0.01 sec) #只删除了一条记录(通过缓存命中)
mysql> select * from employee; +-----+------+-------------+ | id | name | sharding_id | +-----+------+-------------+ | 101 | dn03 | 3 | #dn03上的记录仍然存在 +-----+------+-------------+ 1 row in set (0.00 sec)
mysql> explain select * from employee where id=101; +-----------+-------------------------------------+ | DATA_NODE | SQL | +-----------+-------------------------------------+ | dn00 | select * from employee where id=101 | #再通过主键查询,仍到dn00分片上执行 +-----------+-------------------------------------+ 1 row in set (0.00 sec)
mysql> select * from employee where id=101; #dn03分片上的记录并未查询出来 Empty set (0.00 sec)
mysql> show @@cache; +---------------------------------------+-------+------+--------+------+------+---------------+---------------+ | CACHE | MAX | CUR | ACCESS | HIT | PUT | LAST_ACCESS | LAST_PUT | +---------------------------------------+-------+------+--------+------+------+---------------+---------------+ | ER_SQL2PARENTID | 1000 | 0 | 0 | 0 | 0 | 0 | 0 | | SQLRouteCache | 10000 | 2 | 19 | 9 | 2 | 1513330571512 | 1513328908328 | | TableID2DataNodeCache.TESTDB_ORDERS | 50000 | 0 | 0 | 0 | 0 | 0 | 0 | | TableID2DataNodeCache.TESTDB_EMPLOYEE | 10000 | 1 | 9 | 7 | 1 | 1513330571512 | 1513329310256 | +---------------------------------------+-------+------+--------+------+------+---------------+---------------+ 4 rows in set (0.00 sec) #缓存中该主键值的缓存仍然存在
8. 回到第7步,若不按主键删除,而是按分片字段删除。则只会删除指定分片的记录,其它分片的记录不会被删除。
mysql> delete from employee where sharding_id=3; Query OK, 1 row affected (0.01 sec) #删除了指定分片的记录
mysql> select * from employee; +-----+------+-------------+ | id | name | sharding_id | +-----+------+-------------+ | 101 | dn00 | 3 | #其它分片的记录仍存在 +-----+------+-------------+ 1 row in set (0.00 sec)

标签:mysql,Mycat,数据分布,分片,employee,主键,101,id
From: https://www.cnblogs.com/tiancai/p/16899735.html

相关文章

  • Elasticsearch 集群内应该设置多少个分片(shard)?
    我应该设置多少个分片?我应该设置多大的分片?Elasticsearch是一个功能十分丰富的平台,支持各种用例,能够在数据整理和复制战略方面提供很大的灵活性。然而这一灵活性有时也会带......
  • Mycat代理
    Mycat代理笔记Mycat简介什么是mycatmycat是Java语言开发的目前比较主流的数据库中间件之一,是mycat团队在阿里开源的Cobar产品基础上而研发的,也一直在维护。my......
  • Redis Cluster 数据分片
    介绍RedisClusterRedis集群是Redis提供的分布式数据库方案,集群通过分片(sharding)来进行数据共享,并提供复制和故障转移功能。节点一个Redis集群通常由多个节点(no......
  • Redis Cluster 数据分片
    介绍RedisClusterRedis集群是Redis提供的分布式数据库方案,集群通过分片(sharding)来进行数据共享,并提供复制和故障转移功能。节点一个Redis集群通常由多个节点(n......
  • MongoDB集群之复制集,分片
    目录1集群1.1简介1.2复制集1.2.1简介1.2.2复制集设置1.2.2.1创建目录并启动1.2.2.2配置及初始化1.2.2.3操作节点1.2.2.4不正常关闭服务1.3分片1.3.1简介1.3.2......
  • ElasticJob‐Lite:作业分片策略介绍与源码分析
    分片弹性调度是​​ElasticJob​​​最重要的功能,也是这款产品名称的由来。它是一款能够让任务通过分片进行水平扩展的任务处理系统。​​ElasticJob​​​中任务分片项的......
  • mycat负载均衡集群
    1.haproxy负载均衡搭建与介绍在网站创立初期,我们一般都使用单台机器对台提供集中式服务,但随着业务量越来越大,无论性能还是稳定性上都有了更大的挑战。这时候我们就会想到......
  • mycat2 安装、分库分表、以及集群的搭建
    搭建双主双从 一个主机m1用于处理所有写请求,它的从机s1和另一台主机m2还有它的从机s2负责所有读请求。当m1主机宕机后,m2主机负责写请求,m1、m2互为备机。......
  • JavaScript超大文件上传解决方案:分片断点上传
    ​ javaweb上传文件上传文件的jsp中的部分上传文件同样可以使用form表单向后端发请求,也可以使用ajax向后端发请求    1. 通过form表单向后端发送请求    ......
  • mongodb 分片键的特点及分片原则
    mongodb分片键的特点,选择条件及分片原则1、集群cluster:包含多个分片分片shard:包含多个chunk块chunk:包含多个文档文档doc:包含shardkey的一行数据片键shardkey:文档......