mysql集群主主模式缺点 mysql集群和主从哪个好

一、MySQL高可用集群方案

### --- 主从复制+读写分离

~~~     此种架构，一般初创企业比较常用，也便于后面步步的扩展, 
~~~     客户端通过Master对数据库进行写操作，
~~~     slave端进行读操作，并可进行备份。Master出现问题后，可以手动将应用切换到slave端。

### --- 主从复制的优点：

——>        1. 实时灾备，用于故障切换(高可用)
——>        2. 读写分离，提供查询服务(读扩展)
——>        3. 数据备份，避免影响业务(高可用)

### --- 读写分离的优点:

——>        1. 主从只负责各自的写和读，极大程度的缓解锁争用
——>        2. 从库可配置myisam引擎，提升查询性能以及节约系统开销
——>        3. 从库同步主库，通过主库发送来的binlog恢复数据
——>        4. 读写分离适用与读远大于写的场景，如果只有一台服务器，
——>        当select很多时，update和delete会被这些select访问中的数据堵塞，
——>        等待select结束，并发性能不高。 对于写和读比例相近的应用，应该部署双主相互复制

二、双主从复制

### --- 双主从复制

——>        很多企业刚开始都是使用MySQL主从模式，一主多从、读写分离等。
——>        但是单主如果发生单点故障，从库切换成主库还需要作改动。
——>        因此，如果是双主或者多主，就会增加MySQL入口，提升了主库的可用性
——>        双主模式是指两台服务器互为主从，任何一台服务器数据变更，
——>        都会通过复制应用到另外一方的数据库中。

### --- 问题: 使用双主双写还是双主单写？

——>        建议大家使用双主单写，因为双主双写存在以下缺点：
——>        ID冲突：在A主库写入，当A数据未同步到B主库时，对B主库写入，
——>        如果采用自动递增容易发生ID主键的冲突。可以采用MySQL自身的自动增长步长来解决，
——>        例如A的主键为1,3,5,7...，B的主键为2,4,6,8... ，但是对数据库运维、扩展都不友好。
——>        更新丢失：同一条记录在两个主库中进行更新，会发生前面覆盖后面的更新丢失。

三、MMM架构

### --- MMM架构

——>        MMM(Master-Master Replication Manager for MySQL)是一套用来管理和监控双主复制，
——>        支持双主故障切换 的第三方软件。MMM 使用Perl语言开发，虽然是双主架构，
——>        但是业务上同一时间只允许一个节点进行写入操作。下图是基于MMM实现的双主高可用架构。

### --- MMM故障处理机制

——>        MMM 包含writer和reader两类角色，分别对应写节点和读节点。
——>        当 writer节点出现故障，程序会自动移除该节点上的VIP
——>        写操作切换到 Master2，并将Master2设置为writer
——>        将所有Slave节点会指向Master2
——>        除了管理双主节点，MMM 也会管理 Slave 节点，在出现宕机、
——>        复制延迟或复制错误，MMM 会移除该节点的 VIP，直到节点恢复正常。

四、MHA架构

### --- MHA架构
### --- MHA Manager管理多组主从复制

——>        MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案，
——>        它由日本人开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。
——>        在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，
——>        并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
——>        目前MHA主要支持一主多从的架构，要搭建MHA,
——>        要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，
——>        一台充当备用master，另外一台充当从库

### --- 该软件由两部分组成：MHA Manager(管理节点)和MHA Node(数据节点)。

——>        MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，
——>        也可以部署在一台slave节点上。
——>        MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，
——>        当master出现故障时，它可以自动将最新数据的slave提升为新的master，
——>        然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

### --- MHA故障处理机制：

——>        把宕机master的binlog保存下来
——>        根据binlog位置点找到最新的slave
——>        用最新slave的relay log修复其它slave
——>        将保存下来的binlog在最新的slave上恢复
——>        将最新的slave提升为master
——>        将其它slave重新指向新提升的master，并开启主从复制

### --- MHA优点：

——>        自动故障转移快
——>        主库崩溃不存在数据一致性问题
——>        性能优秀，支持半同步复制和异步复制
——>        一个Manager监控节点可以监控多个集群