Mysql集群

1 主从模式

• 一个master可以拥有多个slave，一个slave只对应一个master
• 一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。
• 所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。
• 一主多从的结构，主要目的是实现数据的多点备份（没有故障自动转移和负载均衡）

缺点：

• 从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。
• 对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
• 单一的主节点挂了，将不能对外提供写服务。

1.1 Mysql主从复制工作原理

数据库的主从同步，就是为了要保证多个数据库之间的数据保持一致。

• 最简单的方式就是使用数据库的导入导出工具，定时将主库的数据导出，再导入到从库当中。这是一种很常见，也很简单易行的数据库集群方式。但是这种方式进行数据同步的实时性比较差。

• 如果要保证数据能够实时同步，对于MySQL，通常就要用到他自身提供的一套通过Binlog日志在多个MySQL服务之间进行同步的集群方案。

Binlog复制流程详解：

• 主库上打开Binlog日志，记录对数据的每一步操作
• 当主库有数据更新的时候，会通知从库
• 从库会向主库请求binlog日志，但为了保证日志接收的稳定性，并不会立即重演Binlog数据操作，而是先将接收到的Binlog日志写入到自己的RelayLog日志当中
• 从库检测到RelayLog中的操作日志有更新，就会在自己数据库中进行异步重演。

MySQL的BinLog日志能够比较实时的记录主库上的所有日志操作，因此他也被很多其他工具用来实时监控MySQL的数据变化。如：

• 转发到Redis实现缓存一致
• ClickHouse也支持将自己模拟成一个MySQL的从节点，接收MySQL的Binlog日志，实时同步MySQL的数据。这个功能目前还在实验阶段。

1.2 主从复制的策略

1. 「同步策略」：Master会等待所有的Slave都回应后才会提交，这个主从的同步的性能会严重的影响。
2. 「半同步策略」：Master至少会等待一个Slave回应并写入relay log后提交。
3. 「异步策略」：Master不用等待Slave回应就可以提交。

1.3 日志记录上position方式和GTID方式区别

• 主从复制,默认是通过pos复制(postion)方式,将用户进行的每一项操作都进行编号(pos)，在配置从服务时，就需要通过这个Position通知从服务从哪个地方开始记录binLog。
• GTID (Global Transaction ID全局事务ID)就是类似于pos的一个作用,全局通用并且日志文件里事件的GTID值是一致的。不用以前那样在需要找log_file和log_Pos。
• 从架构设计的角度，GTID是一种很好的分布式ID实践方式

2 MySQL Fabric 模式

• MySQL Fabric能“组织”多个MySQL数据库，是应用系统将大于几TB的表分散到多个数据库，即数据分片(Data Shard)。
• 在同一个分片内又可以含有多个数据库，并且由Fabric自动挑选一个适合的作为主数据库，其他的数据库配置成从数据库，来做主从复制。
• 在主数据库挂掉时，从各个从数据库中挑选一个提升为主数据库。

3 MySQL Cluster 模式

• MySQL Cluster是多主多从结构的

可参考redis cluster

4 第三方优化

4.1 MMM 模式

• MMM（Master Replication Manager for MySQL）是双主多从结构。

• 这是Google的开源项目，使用Perl语言来对MySQL 主从做扩展，提供一套支持双主故障切换和双主日常管理的脚本程序，主要用来监控mysql主主复制并做失败转移。

• 他需要两个Master，同一时间只有一个Master对外提供服务，可以说是主备模式。

• 他是通过一个VIP(虚拟IP)的机制来保证集群的高可用。整个集群中，在主节点上会通过一个VIP地址来提供数据读写服务，而当出现故障时，VIP就会从原来的主节点漂移到其他节点，由其他节点提供服务。

4.1.1优点：

• 提供了读写VIP的配置，使读写请求都可以达到高可用

• 工具包相对比较完善，不需要额外的开发脚本

• 完成故障转移之后可以对MySQL集群进行高可用监控

4.1.2 缺点：

• 故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率

• 目前MMM社区已经缺少维护，不支持基于GTID的复制

4.1.3 适用场景：

• 读写都需要高可用的

• 基于日志点的复制方式

4.2 MHA 模式

• MHA（Master High Availability）是多主多从结构，
• 是由日本人开发的一个基于Perl脚本写的工具。这个工具专门用于监控主库的状态，当发现master节点故障时，会提升其中拥有新数据的slave节点成为新的master节点，在此期间，MHA会通过其他从节点获取额外的信息来避免数据一致性方面的问题。
• MHA还提供了mater节点的在线切换功能，即按需切换master-slave节点。MHA能够在30秒内实现故障切换，并能在故障切换过程中，最大程度的保证数据一致性。

4.2.1 优点：

• MHA除了支持日志点的复制还支持GTID的方式

• 同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。

4.2.2 缺点：

• MHA需要自行开发VIP转移脚本。

• MHA只监控Master的状态，未监控Slave的状态