关于MySQL集群的一些看法

作者：Gary Chen
链接：https://zhuanlan.zhihu.com/p/20204156
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

市面上的招聘往往要求DBA精通MySQL集群，实际上，应该指得是MySQL复制。由于MySQL cluster应用场景很少且很复杂，所以国内擅长MySQL cluster的DBA其实是很少的。许多人/公司还停留在试用阶段。

由于数据量的不断增加，读写吞吐的不断增加，业务对于数据库的高可用/高吞吐要求越来越高，单个节点往往承载不了工作负荷，如果我们拥有一个多节点的集群，可以把数据分布在多个节点，多个节点同时对外提供部分或者全部服务，那么将可以大大改善我们系统的可用性和扩展性。

在现实领域，由于MySQL集群产品的复杂性和维护成本，DBA往往并不倾向于采用这种方案，特别是DBA本身成为工作瓶颈的情况下，当然DBA希望方案越简单越好，而MySQL主从就是最简单的方案。

数据库的扩展一般可分为读的扩展、写的扩展以及数据量的扩展。对于读的扩展，通过复制架构，增加更多的从库，是可以大大缓解读的，而在合适的时机使用缓存架构，是普遍认为更良好的一种解决方案。缓存的方案也可以比MySQL自身的从库更高效的处理工作负荷。

复制架构扩展读，需要考虑的一个问题是读的一致性，由于一些数据对于复制延时是敏感的，你可能不能简单的从从库读取，而是仍然从主库读取，以获得强一致性，所以，对于你的数据，你一定要清楚，明确知道各种数据对于时间的敏感度，分别加以处理，这种处理工作在应用层处理成本会更少，更好处理。

MySQL复制为了获得各种级别的一致性，有异步、半同步、强同步之分，对同步要求越高，对性能影响最大。一般生产环境，我建议仍然是采用异步复制的方式，这也是默认的，如果真的需要很高的一致性，我觉得从应用的访问策略解决更好，直接从主库或者缓存中读取是更优雅的处理方式。

对于MySQL复制集群，实例数比较少，DBA往往可以手动处理，如果你拥有大量实例，那么需要更自动化的方案，网上有一些开源的方案，大家可以参考，比如MHA，Proxy的方案也是可行，可以更透明的处理节点异常，在5.6 gtid实现后，MySQL的节点复制的异常处理，已经变得比以前简单多了，相对低版本来说，自动化程度也可以更为提高，自动化方案也会更稳健。

传统的技术仍然有一定的用武之地，比如基于存储层的同步，MySQL提供了一个软raid的方案DRBD, 据说也有许多人采用这个方案，但是我认为，这种方案是不可取的，现在的PC服务器已经很强劲，基于主机之间做故障切换是主流，我们设计方案也应该从这点出发，主库如果不可用，就把流量切换到从库。如果使用DRBD这样的方案，意味着有一边节点是不能用的，而且切换的时间也很可能达不到你的需求。在一个，DRBD可能自身成为整个系统的评价，因为现在的SSD硬盘已经很快了，网络raid反而成为瓶颈，限制了性能/吞吐。

对于写的扩展，复制架构其实无助于解决问题，如果不能从应用层减少数据的写入，我们只能进行垂直或者水平的拆分，把数据的写入平均分布到多个节点，sharding的技术方案这个时候会用到，对于sharding的策略，不要求很自动化或者扩展很多倍，但预先进行sharding策略是需要的，如果你的业务真的可能有大量的数据增长。常见的一个问题是，软件设计人员不清楚硬件，往往预留了太多的扩展空间，这点可以通过和硬件运维团队、DBA加以沟通尽量避免。

数据库的写的优化，和其他应用程序的写入优化差不多，减少写的次数、减少写的频率、批量写、合并写、压缩、利用 时间/空间的局部性，你需要选择的是，在应用层做呢，还是在数据库的层次做。对于很大的的字段，如果实际是可以获得很高压缩比的话，比如是文本，MySQL 5.6的压缩表，是值得考虑尝试的。

我倾向于数据库控制在1个T以下，并不是说MySQL就处理不来超过1T的数据，而在于这种有的方式更可控，基于经验认为这样的数据量 单个实例，是比较成本平衡的，MySQL对于大数据量的备份，仍然存在一些带解决的问题。所以如果集群有多个节点，能在多个节点分别备份，那么基于每个节点的备份/恢复也会快的多的。

有一个观点认为，集群有更多的节点，那么可以容错性更高，因为单个节点可能只负责部分访问，那么单个节点的失效，整个系统仍然大部分可用，这取决于你的系统的设计，如果你的集群系统是松散耦合的，单个节点不怎么影响整个系统，那么这种想法是有道理的，如果单个节点可能导致整个系统不可用，那么多个节点，可能导致更多的问题出现，显而易见的情况是，数据分布到多台机器，出故障的概率肯定是要多了，如果没有一套自动化的发现和处理问题的手段，那么必然意味着管理维护成本的攀升。

有人使用官方的MySQL cluster，也有人使用percona公司出品的Percona XtraDB Cluster， 但由于使用的人少，务必做好充分的测试验证工作，你可能碰到许多问题需要小心加以避免。这些产品在解决问题的同时，往往带来一些新的问题。

基于目前的官方文档，MySQL cluster是紧耦合设计的，对于节点之间的网络要求很高，而Percona XtraDB Cluster相对来说是松耦合设计，容错性更高，这方面我没有足够的经验。有想使用cluster的同学，建议从试用Percona XtraDB Cluster开始。