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

作为一个中间层，本职工作应该是接收客户端的SQL请求，然后通过语法分析，根据读写原则，然后确定一个集群中一个读写节点即可，然后就等着结果集的返回，对于结果集本身，中间层并不需要去关心，他只需要将结果集(或者异常)原原本本发回给客户端即可。而MyCat做的事情，远比这个多，在语法分析之后，再做语义分析，拿到对应数据库表结构，同时判断这个表的分发路由规则，再找到语句中的数据及涉及到的列，再决定路由到哪个分片中，如果在分发时路由规则配置错误，或者程序计算错误，会导致整个语句的结果出现不可预知的问题。请问这前半部分，是一个中间层应该做的事情么?竟然还要关心语句中涉及到的表结构，主键，数据等信息，这其实都是数据库要做的事情啊，实则是越俎代庖，再请问，所做的这些事情，能比一个专业数据库做得更好么?咱再看后半部分，等收到结果集之后，MyCat为了处理一些结果集的聚合计算，需要把各个节点本来已经封装好的结果集(二进制MySQL协议流数据)，解析出来，然后通过需要计算出来(这个计算有可能非常慢，并且不是所有的都可以搞定)，计算完成之后，再打包成MySQL协议流数据，传给客户端，请问这样的中间层，做了这么多事情，性能如何保证?而本身这些聚合计算Order By、Group By的处理，本身是数据库的事情，实则还是越俎代庖。

通过SQL语句的变换，实现分布式是不是有点困难?

MyCat这种中间层，代表了宣称分布式数据库的一类使用方式，但这种实现方法实际上都是通过在SQL语句上做文章，从客户端拿到的是SQL语句，给后端数据库的也是SQL语句，但这两个SQL语句是经过变换的，当然这种方法也只能这样，因为后端数据库只接收SQL语句，试问，一个复杂的SQL语句查询操作，通过SQL变换或重写，就能实现对不同分片数据库的分布式查询?想想就清楚了，虽然SQL语句通用灵活，但可扩展性或者重写的逻辑还是有点复杂的吧?当然了，有人可能会说，我们有兜底的啊，大不了把这个语句就改一下库名表名然后其它保持不变分给每一个节点去执行，这样总没问题吧，是的，你说的没错。

在同一个事务中要修改不同节点的数据是如何处理的?

这个问题就是我们通常所说的分布式事务了，究竟是怎么回事呢，MyCat下面对的是MySQL Server，也就是说MyCat只能用SQL语句与MySQL Server交流，这样就是局限于MySQL的SQL语句的功能了，那在分布式实现上面，MySQL XA本身有多少人用，MyCat如果实现一个跨节点的数据更新，不用MySQL XA，还能用其它什么?别无他选，本身依赖一个没有太多人用，并且可能存在很多问题，包括性能，Bug的功能，这样上层MyCat乃至应用程序的可靠性如何保证?当然基于这些问题，有些方案选择不用XA，如果某些节点失败了，选择忽略不解决，这当然也可以，妥协嘛————不需要底线的。

MyCat后端数据库的架构是什么，如何保证稳定可靠高可用?

这个据某些文章宣传说，之前可以选择主从复制，现在可以选择Galera Cluster，或者也可以选择更新的MGR，当然不得不说，从前到后，可能确实保证了更好的可靠性，但有一个很大的问题是，Galera的门槛比较高，遇到问题的话，很少人能解决掉(很自豪的是，去哪儿可以称得上全球为数不多的使用Galera比较多并且使用的比较好的公司)，再到MGR，本身还得等，能用还要比较长的时间，这问题还是要回到主从复制，这是老问题了，主从复制的一致性很难保证，MyCat如果通过读写分离策略将读打到从上面，而这个正好有延迟，这样产生的后果可能是整个应用程序的计算结果是错误的，当然可以说有延迟检查，那问题是，延迟检查的话，是不是还有一个参数可以配置呢?如果延迟超过100秒的话就去查主库?没错，不过100秒难道就不是延迟了?那可以设置为0，看到的0，你以为真的是0?其实还是主从复制的劣根性。所以问题还是回到了起点，经济基础决定上层建筑，基础不好，上层如何是好?

分片多了的情况下，性能是如何保证损失最小的?

这个问题，我并不知道MyCat有没有做过优化，比如10个分片，如果一个语句的执行会涉及到这十个分片，那在每个分片上重写语句之后，就要分别在这十个分片上执行对应的语句了，执行时是串行，还是并行?串行的话，性能必然会下降10倍以上，所以做得好点的话，就是并行了，但并行的实现方法是，在MyCat这个连接上面，创建10个线程，去处理这十个节点的执行情况，那这样的连接多了，MyCat产生的对系统的冲击就非常大了，性能还是不行。当然也可以说，这里做了连接池，没错，是可以的，但MyCat是这样做的么?这样做了性能又如何呢?如果有一个超时，整个访问就失败了。

配置文件或者配置库出问题，整个集群会出现什么情况?

前面已经说了，MyCat用的是schema.xml来配置的分库分表策略，这是一个配置文件，MyCat本身的高可用，如果配置多套的话，他们的同步问题，是如何解决的?如果没有同步(或者同步出问题，或者延迟等)，某一个MyCat挂了，业务切换到其它的MyCat时，此时的情况就是，故障……故障……。因为数据都乱了。有可能造成的问题是，写入了错误的位置，进而导致整个集群的数据被写坏。感觉比直接被删了还严重。同样的问题，感觉MyCat可能会优化这点，也许会改为将其集中存储在某一个数据库中，这样集中管理的话就不需要同步了，想法是好的，但这相当于是把鸡蛋放在一个篮子里面了，如果这个配置库出问题了，业务何去何从?

DDL如何进行?

这个问题也许是每个人都关心的事情了，MyCat把数据都分而不相关的分片MySQL节点了，这样很多在单点上的改表策略都不能用了，而DDL又是一个必须要保证每个节点同时完成的事情，那在分布式上面是如何保证的呢?根据我的调研，好像现在使用MyCat的人，都是通过“同一时刻启动在每一个节点上更新表结构”这样的方法来做的，当然还得选择是半夜，当然我个人觉得也是可行的，因为毕竟已经使用了它，而没有更好的办法来解决这个问题。当然咱再说后果，如果做不到无缝原子修改，那对业务的影响不是一星半点，可能会有很多SQL会报表不存在的问题。如果一个语句和另一个语句修改完成时间相差比较多的话，两个相减的时间就是故障时间了。

据我调研，MyCat还实现了自动故障切换的功能，请问这个靠谱么?

（编辑：三明站长网）

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