MySQL企业常用集群架构

     纠结了很久，想使用磁盘技术彻底解决mysql集群架构，使用了GFS2，但暂时无法解决磁盘I/O问题；使用了GlusterFS，发现又不建议服务器长时间保持开机状态下使用，DRDB也只能解决mysql的高可用问题，又考虑到负载，考虑到成本，所以最后还是需要配合使用，询问同行朋友，大多数公司都是下列架构；

       做读写分离，通过mysql自带的同步方案replication实现数据同步，使用分布式文件系统切换关键节点，解决单点问题；

下文仅供参考，借鉴而来，具体配置，后续发布；

1、mysql企业常用集群架构

在中小型互联网的企业中。mysql的集群一般就是上图的架构。WEB节点读取数据库的时候读取dbproxy服务器。dbproxy服务器通过对SQL语句的判断来进行数据库的读写分离。读请求负载到从库（也可以把主库加上），写请求写主库。

这里的dbproxy是数据库集群的唯一出口所以也需要做高可用。

drproxy是数据库读写分离的常用软件，amoeba、mycat、cobar也很常用。这类软件不仅带有读写分离功能，还可以实现负载均衡以及后端节点的健康检查。

数据库的读写分离除了通过这类数据库中间件软件实现，还可以写在程序中。

通常我们的主库要做双主高可用，实现主库挂掉另一个主库立刻接管。如果不做双主，从库接管主库的时候需要做状态迁移，会有延迟。

数据库主库的高可用重点需要考虑的是数据同步。比较常用的高可用方案有：

1、keepalived+mysql replication。通过keepalived实现VIP飘逸，通过mysql自带的同步方案replication实现数据同步。

2、hearbeat+drbd。通过drbd实现双主数据的同步，这个数据同步是基于块设备的。比一般的同步方案要快很多。通过heartbeat实现VIP漂移以及drbd资源的切换管理。

3、keepalived+mha。

对于从库，最好不要超过5个。我们可以把其中的三个作为用户访问的节点，把另外一个作为内部人员的查询节点。因为内部人员查询节点的时候一般是按照时间段查询，不经过索引，占用的资源比较多，所以要把这个节点单独专用，以免影响客户访问。最后我们应该留一个从库进行数据库的数据备份。

从库的数据一致性保持可以通过直接于主库进行主从辅助，也可以从其他从库那进行主从复制（优点是减少主库压力，缺点是延迟稍大）。

2、MYSQL数据架构

数据库服务器==》数据库（多个实例）==》多个库==》多个表==》多个字段行列（数据）

在一台数据库服务器上可以跑多个实例，一个实例中有多个库，一个库有多个表，一个表有多个行列。