主库记录二进制日志。在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引擎可以提交事务了。下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库启动一个特殊的二进制转储线程，这个二进制转储线程会读取主库上二进制日志中的事件。他不会对事件进行轮询。如果该线程追赶上了主库，他将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会被唤醒，备库I/O线程会将接收到的事件记录到中继日志中。
备库 的SQL线程执行最后一步，该线程从中继日志中读取事件并在备库执行，从而实现备库数据的更新。当SQL线程追赶上I/O线程时，中继日志通常已经在系统缓存中，所以中继日志的开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写入其自己的二进制日志中，它对于我们稍后提到的场景非常有用。这种复制架构实现了获取事件和重放事件的解耦，允许这两个过程异步进行。也就是说I/O线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要的一点是在主库上并发运行的查询在备库只能串行化执行，因为只有一个SQL线程来重放中继日志中的事件。这也是很多共组欧服在的性能瓶颈所在。虽然有一些针对该问题的解决方案，但大多数用户仍然受制于单线程。MySQL5.6以后，提供了GTID多开启多线程同步复制的方案，即每个库有一个单独的sql thread。
进行同步复制，之将大大改善MySQL主从同步的数据延迟问题，配合mycat分片，可以更好地将一个超级大表的数据同步的时延降低到最低，此外，用GTID避免了在传送binlog逻辑上依赖文件名和物理偏移量，能够更好的支持自动容灾切换，对运维人员来说应该是一件令人高兴的事情，因为传统的方式里，需要找到binlog和pos点，然后change master to 指向，而不是很有经验的运维，往往会将其找错，造成主从同步复制报错，在mysql5.6里，无需再知道binlog和pos点，需要知道master的IP和端口以及账号密码即可，因为同步复制是自动的，mysql通过内部机制GTID自动找点同步。
即使是并发复制机制，仍然无法避免主从数据库的数据瞬间不同步的问题，因此又有了一种增强的方案，即galera for mysql、percona-cluster或者mariadb cluster等集群机制，他们是一种多主同步复制的模式，可以在任意节点上进行读写、自动控制成员、自动删除故障节点、自动加入节点、真正给予行级别的并发复制等强大能力。