前言

单机版mysql容易出现单点故障，所以需要搭建多台mysql服务器，mysql架构有很多种，目的都是热备份，多活，故障切换，负载均衡、读写分离等

一、主从复制架构

master主节点负责写入数据，slave从节点负责读取数据。实现了读写分离。应用与读多写少的业务场景。这种架构的缺点就是只有一个master,如果挂掉了，就无法写入数据了。而且master和slave数据还有同步延迟的风险。

这种架构是级联复制架构，用于解决读需求更多的业务场景。如果读压力加大，就需要更多的slave来解决，但是如果slave的复制全部从master复制，势必会加大master的复制IO的压力，所以就出现了级联复制，减轻master压力。缺点就是slave延迟更加大了。

二、主主架构

两个主节点，一个负责写，一个负责读，需要配合一个keepalived进行ip漂移，这样一个挂掉了，另一个可以继续工作。

上面这种架构，双主多从，解决了单master复制的压力大问题，减少了slave数据延迟，且双master可以减少单点故障。

由上面的架构可以看出，搭建mysql集群是一个很大的开销，绝大多数公司，用的还是单机版mysql。

三、MYSQL主从复制原理

• 复制过程-异步复制 异步复制是MYSQL主从复制默认的方式，流程如下: 1.客户端提交sql语句至master的mysql服务器后，mysql服务器将sql语句写入binglog日志。并将事务进行提交，返回消息给客户端。 2.mysql服务中有个event监听器，监听binglog日志的变化，如果有变化，则通知dump线程。 3.master服务器的dump线程通知slave服务器的IO线程，有数据需要同步，slave服务器的IO线程从slave服务器的relay-log.info中获取binlog文件和pos位置(类似于Kafka中的偏移量，记录binlog日志的插入位置) 4.slave节点通过IO线程通知master节点slave的binlog文件和pos位置 5.根据slave的请求，master将相应的binlog文件和pos位置传给slave 6.slave获取到信息后，将信息写入relay-bin日志中。等待slave节点从relay-bin读取日志，同步数据。 7.slave节点写入relay-bin日志成功后，给master节点回复ack信息，通知master写入relay-bin日志成功。 8.master节点的dump线程通知服务将客户端写入的数据进行提交操作，然后给客户端相应消息。
• 复制过程-半同步复制 1.客户端提交sql语句至master的mysql服务器后，mysql服务器将sql语句写入binglog日志。 2.mysql服务中有个event监听器，监听binglog日志的变化，如果有变化，则通知dump线程。 3.master服务器的dump线程通知slave服务器的IO线程，有数据需要同步，slave服务器的IO线程从slave服务器的relay-log.info中获取binlog文件和pos位置(类似于Kafka中的偏移量，记录binlog日志的插入位置) 4.slave节点通过IO线程通知master节点slave的binlog文件和pos位置 5.根据slave的请求，master将相应的binlog文件和pos位置传给slave 6.slave获取到信息后，将信息写入relay-bin日志中。等待slave节点从relay-bin读取日志，同步数据。 7.slave节点写入relay-bin日志成功后，给master节点回复ack信息，通知master写入relay-bin日志成功。 8.master节点的dump线程通知服务将客户端写入的数据进行提交操作，然后给客户端相应消息。

可以看出，异步复制中，master节点不管slave节点数据是否同步成功，都会将数据提交，返回客户端成功的消息。这样的风险就是slave节点数据同步不成功的话，客户端并不知道。所以引入了半同步复制，master节点等到slave节点写入relay-bin日志成功后，才提交事务数据，这样更有利于数据的同步性。需要注意的是，开启半同步复制后，如果slave节点挂了，则master一直等待slave节点的ack信息，默认等待10秒，如果还没收到slave的ack，则认为slave节点挂掉了，master节点会自动变成异步复制方式进行。