MySQL半同步Semi-sync原理介绍

若是还不了解Semi-sync能够阅读（Manual | 概述）

1. 优势

当事务返回客户端成功后，则日志必定在至少两台主机上存在。

MySQL在加载并开启Semi-sync插件后，每个事务需等待备库接收日志后才返回给客户端。若是作的是小事务，两台主机的延迟又较小，则Semi-sync能够实如今性能很小损失的状况下的零数据丢失。

2. 缺点

完成单条事务增长了额外的等待延迟，延迟的大小取决于网络的好坏。

Semi-sync不是分布式事务，主库会在本身完成事务后，等待备库接收事务日志。

3. 主机Crash时的处理

 

备库Crash时，主库会在某次等待超时后，关闭Semi-sync的特性，降级为普通的异步复制，这种状况比较简单。

主库Crash后，那么可能存在一些事务已经在主库Commit，可是尚未传给任何备库，咱们姑且称这类事务为"墙头事务"。"墙头事务"都是没有返回给客户端的，因此发起事务的客户端并不知道这个事务是否已经完成。

这时，若是客户端不作切换，只是等Crash的主库恢复后，继续在主库进行操做，客户端会发现前面的"墙头事务"都已经完成，能够继续进行后续的业务处理；另外一种状况，若是客户端Failover到备库上，客户端会发现前面的“墙头事务”都没有成功，则须要从新作这些事务，而后继续进行后续的业务处理。

4. 其余

能够作多个备库，任何一个备库接收完成日志后，主库就能够返回给客户端了。

网络传输在并发线程较多时，一次可能传输不少日志，事务的平均延迟会下降。

"墙头事务"在墙头上的时候，是能够被读取的，可是这些事务在上面Failover的场景下，是被认为没有完成的。

 

semi-synchronous并非100%的保证数据不会丢失，若是master在完成事务并将其发送给slave的时候崩溃，仍然可能形成数据丢失。只是相比于传统的异步复制，semi-synchronous replication能极大地提高数据安全。更为重要的是，它并不慢，MHA的做者都说他们在facebook的生产环境中使用了semi-synchronous（这里），因此我以为真心不必担忧它的性能问题，除非你的业务量级已经彻底超越了facebook或者google。

 

另外，若是是一主多备的话，能够认为备库永远不会挂掉(能够作多个备库，任何一个备库接收完成日志后，主库就能够返回给客户端了)。若是主库挂掉的话，自动或者人工切换到其中任何一个备库，这样客户端会从新操做上面失败的数据(主库可能有了，可也也可能没有上个事物的数据)，由于对于客户端来讲，不管crash的主库是否成功，客户端都会失败，客户端都会对备库从新操做上客户端认为失败的那个事物。基本能够保证了数据的不丢失问题。