Mysql主从库同步原理分析和多线程同步

Replication 是什么?
Mysql的Replication是一个 “异步” 的复制过程，也就是从Master复制到一个Slave上。

Mysql 5.1 多线程实现主从复制
重要的是，从Mysql5.1起，Master与Slave之间的复制过程修改为三个线程来完成。
其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端，使用并行的处理方式。而老版本的主从复制是用一个线程来处理。这样的话，就解决了从库延迟的问题；以及，从库处理Bin_log时，主库又新增数据， 从而带来的数据丢失问题。

主从复制基本过程
主从库的整个复制过程实际上就是：Slave从Master端获取Binary log然后再按顺序的执行日志中所记录的各种操作。

• Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容
• Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置
• Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”
• Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的

Mysql主从延迟问题的解决
当然，即使是换成了现在这样两个线程来协作处理之后，同样也还是存在 Slave 数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事务中，这些问题都是存在的。
如果要完全避免这些问题，就只能用 MySQL 的 Cluster 来解决了。不过 MySQL的 Cluster 仍然还是一个内存数据库的解决方案，也就是需要将所有数据包括索引全部都 Load 到内存中，这样就对内存的要求就非常大的大，对于一般的大众化应用来说可实施性并不是太大。

http://www.auu.name/1042/index.html