复制技术的演进可以分为:基于数据安全的复制,基于效率的复制
基于数据安全的复制
异步复制
参考:
https://baijiahao.baidu.com/s?id=1639394556343861204&wfr=spider&for=pc
https://baijiahao.baidu.com/s?id=1638551432748478470&wfr=spider&for=pc
https://www.cnblogs.com/f-ck-need-u/p/9155003.html
首先确保master数据库上开启了二进制日志，这是复制的前提。
在slave准备开始复制时，首先要执行change master to语句设置连接到master服务器的连接参数，在执行该语句的时候要提供一些信息，包括如何连接和要从哪复制binlog，这些信息在连接的时候会记录到slave的datadir下的master.info文件中，以后再连接master的时候将不用再提供这新信息而是直接读取该文件进行连接。
在slave上有两种线程，分别是IO线程和SQL线程。
IO线程用于连接master，监控和接受master的binlog。当启动IO线程成功连接master时，master会同时启动一个dump线程，该线程将slave请求要复制的binlog给dump出来，之后IO线程负责监控并接收master上dump出来的二进制日志，当master上binlog有变化的时候，IO线程就将其复制过来并写入到自己的中继日志(relay log)文件中。
slave上的另一个线程SQL线程用于监控、读取并重放relay log中的日志，将数据写入到自己的数据库中。如下图所示。
半同步复制
MySQL在2010年5.5版本之前，一直采用的是异步复制。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失。
MySQL在5.5中引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中。那么半同步复制是否可以做到不丢失数据呢。
早期的半同步复制缺点:
在正常的半同步复制流程中,客户端发起事务提交后,主库发送binlog给从库,从库接受binlog并返回ack,然后主库返回事务提交成功的消息给发起提交的客户端,看似没有问题,但实际上主库在等待ACK的过程中innodb存储引擎内部已经提交事务,只是阻塞了返回给发起事务提交的客户端消息而已,此时如果有其他会话对该事务修改的数据进行查询,将会查到最新数据.