大规模MySQL运维陷阱：使用MyCat踩坑篇

引子

分布式数据库，已经进入了全面快速发展阶段，这种发展，是与时俱进的，与人的需求是分不开的，因为现在信息时代的高速发展，导致数据量和交易量越来越大。这种现象首先导致的就是存储瓶颈，因为MySQL数据库，实质上，还是一个单机版本的数据库，而只要是单机，就必然会遇到的一个问题就是存储问题，因为存储是硬需求，而CPU和内存如果不够的话，只是性能不好，并不会直接否定方案或者架构。

存储问题的解决，其实我们每一家公司或者个人，都一直在努力着。解决方案大概有三个方面：

增大磁盘

这种方式，应该是最直接，最简单的方案了，因为磁盘空间不足了，当然加磁盘是手到病除，比如现在是800G，可以增加到2T，这是没问题的，如果现在已经达到了2T，当然，还是可以增加到5T的盘，但实际上，这个时候可能DBA就要捏把汗了，这么大数据量的MySQL实例，如何运维?如果数据坏了，如何恢复呢?时间成本呢?5T的数据量，已经非常吓人了，估计在业内各大公司，没有DBA想要自己运维的MySQL实例达到这个量级吧?其实我个人认为，这个已经是不能接受的量了，最合适的最好保持在1T以下即可。超过这个就要想办法了。当然这个数据量不宜达到这个大小的原因，可能会有人考虑到这是性能的问题，其实不然，或者性能问题很小，因为InnoDB采用的是B+树的存储方案，小表最坏情况下没有查到数据是要找3层，也就是3个页面的IO，而大表需要的是4个页面的IO，影响不大。

数据压缩

为了减少数据对磁盘空间的占用，我们通常也会将数据做压缩处理，通过一个语句即可搞定，是InnoDB原生支持的一种方式，一般情况下，会将数据占用减少到原来的三分之一到一半不等，效果还是足够明显的，不过这样处理之后的数据，在性能上会有所下降，对于响应要求比较高的业务，可能需要谨慎考虑一下，但这种方式，可能还是治标不治本，在数据量继续增长的情况下，过段时间之后，依然面临相同的问题，这种情况下，就不能继续使用这种方式来实现了。

数据分片

数据分片的解决方案，现在业内也用得很多，这种方案已经超出了MySQL本身，包括HBase、Redis等也都在使用这种方案，应该说这种方案是最具扩展性的，并且可以称得上是无限扩展，而上面两种方案，根本谈不上扩展性。所以这种方案在业内成为主流，并且这种方案才能称得上是分布式存储，具体的实现也层出不穷，当然也存在优秀的分布式解决方案，也存在一些“伪”分布式方案了。

分布式解决方案需求

扩展性

使用分布式，其实最主要的就是扩展性，如果空间不足了，可以很方便容易的扩展节点个数，并且将数据做新的平衡处理。这个过程要不影响业务使用，对业务透明。

支持事务

分布式数据库，对于业务本身，使用方面与单机区别不大，也就是对业务透明，因为使用MySQL是支持事务的，那么MySQL变身为分布式之后，事务特性还是不能少的，所以整体上看来，还是要支持分布式事务。

SQL语句无限制

业务需求的多样性，导致在SQL需求上面，都是比较广泛的，针对业务的透明性，如果某些SQL语句不支持，那这样导致的问题是，一方面，限制了业务程序的功能和性能，另一方面，导致业务程序与“分布式数据库”的捆绑问题。

性能足够好

使用分布式数据库，其实基本上是对性能的要求比较低的业务才会这样选择，即使是这样，还是性能越高，越多人才会选择这样的分布式数据库。

元数据变更透明性

元数据变更，在任何数据库中都是存在的，在单点情况下，改表操作我们有多种友好的方法来实现，但到了分布式环境下，可能这种操作就成为了问题，因为数据的分片导致了元数据的变更需要多点修改，进而很多问题就来了，比如原子性、数据可见性、正确性等等，所以这是最基本的问题。

底层数据库的高可用性

话说经济基础决定上层建筑，在分布式数据库中也是一样的，如果底层数据库的不稳定，或者数据复制延迟，亦或出现数据不一致的问题，则上层应用的访问正确性就没法保证，所以底层数据库最基本的就是保证数据一致性(高可用)。

流行分布式数据库解决方案

中间件分库分表(伪分布式)

在MySQL界，一个存在很久的话题，就是：

哪个中间件实现的分库分表方案比较好啊?

当然对于同一个问题，不同人有不同的理解，也都具有两面性的特征，有人说好，也有人说不好，我们首先看一下这种方案是如何实现的。

MyCat的实现架构大概上上图所示，其实如果只看图的话，这样的架构真是完美无缺，自动分片，自动聚合，分布均衡都实现的非常好。但事实并非如此。

我们可以通过问答的方式，一步步认清楚这种方式的核心问题：

MyCat如何知道数据分片原理，或者说他是如何决定路由路径的?

这个问题，在图上面是看不出来的，MyCat是如何定义或者决定一条SQL语句的执行方式，或者如何决定去哪里取数据及写入到哪里的?解决这样的问题是需要某一个地方来存储的，它的做法是——schema.xml配置文件，竟然用配置文件来搞定。那这样问题就多了，修改分库分表规则之后，如何保证配置与数据同步更新?即使不使用schema.xml配置文件，而是用数据库存储，那配置规则的变更与数据节节点中数据的迁移，也是没办法保证统一的，势必会对业务造成影响。

如果需要扩展节点了，并且需要做rebalance，如何来做?

很多用户，基本都是重新准备一套集群，或者先把数据一点点手动导出导入，导到目标节点之后，然后去手动修改schema.xml配置文件，然后做一次reload操作，这样就实现了重新路由，但这样同样会导致上面的结果。并且这个过程，需要处理好多数据，处理完成之后各种检查，并且占用空间需要两倍，这样折腾，一个DBA只要干一次，可能就有辞职的冲动。

全局表是什么东西?

MyCat支持一个所谓的全局表，用来解决跨节点数据聚合的问题，实现方法是在每一个分片上面，都创建这样的全局表，它的定义是不怎么修改，查询比较频繁表可以定义为全局表，这样的话在每一个分片节点上，只要用到这个表，就可以实现本地查询连接等操作，是可以解决部分问题，但问题是如果分片多的话(假如分片100个)，如何保证数据一致性?这么多节点的XA事务影响是什么?如果出现不一致或者访问错误，引起的问题就是数据结果错误，这样的结果肯定不是业务想要看到的吧?这还不是最关键的，一个数据库集群，搞这么一个特殊处理的东西是何道理?

MyCat究竟做了什么事情?

（编辑：三明站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!