在MySQL Replication结构中，备库端初次通过CHANGE MASTER TO完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图(大图)：

在主库端一旦有新的日志产生后，立刻会发送一次广播，dump线程在收到广播后，则会读取二进制日志并通过网络向备库传输日志，所以这是一个主库向备库不断推送的过程；

新日志在产生后，只需一次广播和网络就会立刻（<1ms）向发送到备库，如果主备之间网络较好的话（例如RTT<1ms），备库端的日志也就小于2ms了。所以，一般的（依赖于RTT），备库的实时性都非常好。

参考：

1. MySQL Replication Manual

2. 图解"How MySQL Replication Works"

Have fun!

广告：我们寻找靠谱的人 | 感谢作者

这里做一个科普，简单介绍一下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也还是很不完善的，希望能够继续健壮直至稳定。

嗨，谁知道呢？

在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑MySQL_Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。

如何同步

1. 主库将所有的更新操作，写入二进制日志。
2. 从库运行"IO线程"（Slave IO Thread）读取主库的二进制日志。
3. 从库运行"SQL线程"（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。

如何分配请求

1. 目前，这部分需要在应用层实现。
2. 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。
3. 执行查询SQL(SELECT)时，请求从库。

所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。