由一次mycat+mysql水平拆分集群问题引发的思考



近段时间部署和测试了一个mycat+4 Percona+tokudb的水平拆分集群，前段应用是将一类奖状数据不断地写入到这个库中，只有insert操作，前几天运行状态还比较好。

从昨天开始，由于业务量突然增加了一些，磁盘IO负载变得很高，而且仔细分析之后，发现磁盘读的性能远远高于磁盘写的性能，这完全是有问题的。因为insert操作肯定主要是写操作，而且写都是顺序写，读操作应该不会太大。

经过对mycat和mysql多方面的查看，都难以解释的通，不太确定问题的方向和原因。后来与同事沟通，又回到了系统的起点：

先确认cpu，然后确认内存，结果发现内存中cache已经用满，开始用了大量的swap分区，由此为出发点，确认思路如下：

于是再次与同事沟通：

应该就是内存不足，才需要读取swap

top里看一下各个mysql实例占用的内存大小

就你发的这些图来看，是有查询操作。

insert操作因为要维护索引，应该会有跌宕读，但是否会以查询的形式体现我就不确认了

先要确认内存争用是mysql触发，还是其它进程

对于数据库服务器，swap最好不要使用

有些极端的场景，会把swap设置成0，就是为了避免用磁盘上的文件交换

这个会对性能造成很大影响的

你现在可以需要先调小innodb的内存参数，然后将会话相关的参数也都逐个往小了调

先把内存争用降下来

于是根据整个系统的物理内存为48g，各个实例的内存最多为50%，现在四个实例，每个实例分配6g内存，由于tokudb采用的是 非directio的模式 “tokudb_directio = 0”，所以讲各个实例的内存设置为4g，让更多的内存用于系统的cache，使系统读操作都使用系统cache，不使用swap分区，保证内存命中率，减少磁盘IO操作。

这样修改了之后，系统的资源变为：

通过iostat看，写请求也大于读请求了，insert操作的状态正常了：

通过这个问题的处理，我有几点感悟：

1. 对于架构设计和性能方面的问题，还是应该回到最初：

系统资源监控：

cpu

内存

磁盘

网络

总体

对应的stat命令：

vmstat

iostat    iotop

mpstat

ifstat

dstat

深刻理解这些基本的系统资源，原理，查看方法，才能认识清楚性能和架构问题，并找到问题解决的突破口； 

2. 对于水平拆分来说：

聊天记录：

从这个问题的处理也感觉到，硬件资源不足，只有一个机器，只从软件mycat+mysql这种方式进行水平拆分，资源消耗和争用的问题还是比较大的

水平拆分不能只从mycat，mysql软件上水平拆，硬件系统资源也要充分，或者够用才行

不然所有的事务都在一台物理机上，资源争用和问题，还是会很多的；

尤其是面对业务负载压力和变化的时候，即使mycat分片很合理，cpu，内存，磁盘IO这些资源不足，整体性能还是会有很多问题的

光mycat 逻辑上分片还不行

要合理利用硬件 特别是io 资源

防止硬件热点

一个磁盘 分太多的分片是没用的 io 竞争

合理利用 网络io 磁盘 io 内存 cpu

比如rain0 根rain10 几块 盘 每个分片在哪个盘上 这才是真正dba 需要规划的

dba 真正的是规划好这些底层的资源优化

3. 真正好的架构设计，不仅仅是软件的设计，而是整个软件，硬件，业务相互结合和配合的设计。