MySQL的优势:
MySQL是最典型的的开源关系型数据库.同时也是许多常见网站 应用程序和商业产品的首选数据库.在大部分情况下.MySQL都是数据存储的首选.
1.易于使用.功能强大.支持事务 触发器 存储过程等.拥有较多利于管理的工具.
2.可以作为拥有上千万条数据记录的大型数据库.
3.采用GPL开源协议.工程师可以自由的修改源码来定制自己的MySQL系统.
4.MySQL的InnoDB事务性存储引擎符合事务ACID模型.能保证完整 可靠的进行数据存储.
高可用架构1:主从模式
最基本的MySQL高可用架构是主从模式.一台MySQL服务器作为Master(主节点).若干MySQL服务器作为Slave(从节点).在正常情况下.只有Master处理写数据请求.同时Master与Slave通过主从复制技术保持数据一致.当Master发生故障宕机时.某个Slave会被提升为Master继续对外提供服务.这样可以实现MySQL的高可用.
Slave在Master宕机时能够代替它的前提条件是.Slave与Master的数据一致.所以.主从模式具备高可用性的基础是主从复制技术.
1.当Master数据发生变更(包括新增 删除 修改等操作)时.Master将数据的变更日志写入二进制日志文件(下文称binlog).
2..数据库Slave启动I/O线程并与Master建立网络连接.从Master的binlog中读取最新的数据变更日志.
3.Slave的I/O线程收到数据变更日志后.将其保存在中继日志文件(relaylog)的尾部.
4.Slave启动专门的SQL线程从relay log中获取日志.并在本地重新执行SQL语句将数据放回数据库中.使Slave数据库与Master数据库保持一致.
Master提交事务不需要经过Slave的确认.也不管Slave是否已接收binlog.Slave写relay log失败 重新执行SQL语句失败等异常情况并不会被Master感知.所以MySQL主从复制是异步的.Master提交事务完成就直接返回了.
异步方式的主从复制有一个潜在隐患.如果Master在提交事务成功后.但尚未发送binlog给Slave时就出现异常宕机了.那么对MySQL执行主从切换就会造成事务数据的丢失.因为被提升为新Master的Slave并未复制这个事务.为了解决数据丢失的问题.MySQL5.5版本提供了半同步复制模式.Master在提交事务前.会等待Slave接收binlog.当至少有一个Slave确认接收了binlog后.Master才提交事务.具体说.Slave在收到binlog并将其写入relay log后.会向Master发送ACK响应.Master在收到ACK响应后.认为响应发送方Slave已经在relay log中保存了事务.这时才进行提交.
需要注意的是.在半同步复制模式下.Slave向Master发送ACK响应的时机并不是重新执行SQL语句后.而是事务数据被写入relay log后.这样一方面可以缩短Master等待响应时间.另一方面.事务数据已经被持久化.不会发生丢失数据的情况.
半同步复制可以提高主从数据的一致性.但是Master提交事务要等待Slave的确认.所以写性能会受到一定的影响.半同步复制适合对数据性要求高的业务场景.
Master会因向过多的Slave复制数据而压力倍增.这个问题称为复制风暴.所以实际的主从架构可能是一些Slave向Slave复制数据.以减轻Master复制的压力.
高可用架构2:MHA
有了主从的基础.接下来就应该考虑如何检测节点故障和执行自动主从切换.MHA在MySQL高可用领域是一套想当成熟的解决方案.它通常可以在10~30s内完成MySQL主从集群的自动故障检测和自动主从切换.并且在主从切换过程中.它可以最大程度的保证主从数据的一致性.以帮助MySQL主从模式达到真正意义的高可用.
如图所示.MHA有两部分组成.MHA Manager(管理节点)和MHA Node(数据节点).
MHA Manger:
MHA的决策层.负责主动检测Master的故障.检查主从复制状态.执行自动主从切换等,MHA Manger可以管理多个MySQL主从集群.通常被部署在单独的服务器上.
MHA Node:
被部署在每台MySQL服务器上.主要负责修复主从数据的差异.
MHA会实时监测每个MySQL主从集群的Master状态.如果某个Master宕机.MHA则会自动选择数据在最接近Master数据的Slave作为新的Master.然后将其他Slave重新指向新的Master.整个故障转移自动化.且对业务完全透明.
1.MHA Manager周期性地探测Master心跳.如果连续四次探测不到心跳.则认为Master宕机.
2.MHA Manager判断各个Slave的binlog.哪个Slave的binlog数据更接近Master数据.就将哪个Slave作为备选的Master.
3.MHA Node试图通过SSH访问Master所在的服务器.
如果网络可达.那么MHA Node可以获取到Master的binlog数据.MHA Node对比Slave与Master的binlog数据.如果发现Slave数据与Master的binlog数据有差异.则会将差异主动复制到Slave.以保持主从数据一致.
如果网络不可达.那么MHA Node对比各个Slave的relay log差异.并做差异数据补齐.
4.MHA Manager构建新主从关系.将备选Master提升为Master.其他Slave向新Master复制数据.
高可用架构3:MMM
MMM是一个MySQL双主故障切换和双主管理的脚本组件.从字面上理解.它有两个Master.并实现了两个Master的高可用.
Master1:真正的Master.负责处理写请求.
Master2(备用):当Master1宕机时.Master2接替它作为新的Master处理写请求.Master2和Master1相互复制数据.一般采用半同步复制模式.
Slave(若干):向Master1复制数据.并且为了不影响Master1的性能.采用异步复制模式.
mmm-monitor:monitor角色.与各mmm-agent通信以检测MySQL服务器的健康状况.并决策是否主从切换.
mmm-agent:被部署在每台MySQL服务器上.作为节点代理与monitor通信.一方面监测本机MySQL的状态.另一方面执行monitor状态.
write vip:MySQL对外提供写数据服务的虚拟IP地址.只与Master1和Master2其中一个节点绑定.
read vid:MySQL对外提供读数据服务的虚拟IP地址.主要与Slave绑定.
MMM故障转移:
1.agent检测到Master1宕机.或者monitor与Master1 agent在一段时间内通信失败.monitor认为Master不可用.
2.monitor请求Master1 agent.要求Master1移除writer vip.如果Master1所在的机器无法访问.则跳过这一步.
3.monitor请求Master2 agent.要求Master2绑定writer vip.绑定成功后.Master2成为Master对外提供服务.
4.agent请求Slave agent.要求Slave向Master2复制数据.
高可用架构4:MGR
MGR是MySQL5.7.17版本推出的高可用解决方案.它具备如下特性.
一致性高:数据复制基于分布式共识算法Paxos.可以保证多个节点数据的一致性.
容错性高:只要不超过一半的节点宕机.就可以继续对外继续提高服务.
灵活性强:MGR支持单主模式和多主模式.在单主模式下会自动选举Master.在多主模式下每个MySQL节点都可以同时处理写请求.
至少有3个MySQL节点组成一个复制组.一个事务必须经过复制组内超过一半的节点决议通过后才能提交.有三个节点组成一个复制组.Consensus层为Paxos一致性协议层.在事务提交过程中组内节点进行决议.至少有两个节点通过.这个事务才能提交.
如果在不同的MySQL节点上执行不同的写操作发生了事务冲突.那么先提交的事务先执行.后提交的事务被回滚.在多主模式下.由于每个MySQL节点都可以执行写请求.在写请求高并发的场景下发生事务冲突的概率较大.会造成大量事务的回滚.所以官方更推荐单主模式.
在单主模式下.MGR会自动为复制组选择一个Master负责写请求.如果复制组内超过一半的节点与Master通信失败.则认为Master宕机.MGR自动根据各节点的权重和ID标识重新选主.并很容易在各Slave之间达成共识.
由于MGR基于Paxos协议.所以主从节点数据有很强的一致性.可以做到数据不丢失.在一个拥有2N+1个节点的复制组中.MGR可以容忍N个节点发生故障.容错性也很高.
单主模式图:
单主模式流程图:
多主模式架构图:
多主模式流程图:
语雀地址www.yuque.com/itbosunmian...?
《Go.》 密码：xbkk 欢迎大家访问.提意见.