学步园

上图先。

MySQL5.5放出了第一个版本MySQL 5.5 Community Edition - Milestone Release，最大的增强莫过于加入了Semi
Sync Replication的支持（虽然仍不完善）。

这里做一个科普，简单介绍一下Semisynchronous Replication：

1. Why Semisynchronous Replication?

之前版本的MySQL Replication都是异步（asynchronous）的，主库在执行完一些事务后，是不会管备库的进度的。如果备库不幸落后，而更不幸的是主库此时又出现Crash（例如宕机），这时备库中的数据就是不完整的。简而言之，在主库发生故障的时候，我们无法使用备库来继续提供数据一致的服务了。

Semisynchronous Replication则一定程度上保证提交的事务已经传给了至少一个备库。

2. 为什么是Semi synchronous而不是Full synchronous？

Semi synchronous中，仅仅保证事务的已经传递到备库上，但是并不确保已经在备库上执行完成了。

此外，还有一种情况会导致主备数据不一致。在某个session中，主库上提交一个事务后，会等待事务传递给至少一个备库，如果在这个等待过程中主库Crash，那么也可能备库和主库不一致，这是很致命的。（在主库恢复后，可以通过参数Rpl_semi_sync_master_no_tx观察）

3. 如果主备之间连接出现故障，主库是否会一直等待？

如果主备网络故障或者备库挂了，主库在事务提交后等待10秒（rpl_semi_sync_master_timeout的默认值）后，就会继续。这时，主库就会变回原来的异步状态。

4. 最后

且不论5.5是否稳定，现在的Semi synchronous Replication也还是很不完善的，希望能够继续健壮直至稳定。

嗨，谁知道呢？

如果还不了解Semi-sync可以阅读（Manual | 概述）

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

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

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

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

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

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

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

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

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

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

累了，听首歌，伸个懒腰吧:)

转自：http://www.orczhou.com/index.php/2011/07/why-and-how-mysql-5-5-semi-sync-replication/