MySQL5.5.8 binlog主从replication，从库所在主机磁盘满，发现后清理磁盘，得出空余空间。在磁盘满期间，从库报出空间不足的异常，恢复磁盘空间后，从库与主库的数据是否会不一致？还是会将磁盘满期间的数据在清理磁盘后重做？
更新slave在同步master的数据时有会有两个线程，IO线程和SQL线程，前者负责同步master的Binlog日志生成RelayLog，SQL负责根据RelayLog中的内容中执行SQL在slave端进行数据重做。现在虽然slave出了问题，但是情况比较特殊，是磁盘满了。所以我把问题细化下，看看大家对这几个分开的问题怎么理解？
1.假设不是磁盘满的情况下，IO线程同步没有问题，那relaylog将继续与master的binlog同步，但是slave的SQL线程执行出错，此时slave的SQL线程是否会挂起不再继续执行relaylog后续的SQL，还是会自动跳过（亦或是需要手动执行跳过）当前SQL继续执行relaylog后续的SQL？
2.当前的情况是磁盘满，那么relaylog没有空间追加，报出空间不足的异常，这样IO线程是会不管异常如何，继续同步binlog,还是会挂起等待空间恢复后继续同步？如果relaylog无法写入，SQL线程是不是就无新的SQL可执行，同时将会挂起？如果relaylog写完那一刻满了，SQL线程执行SQL要写入数据文件时发现磁盘满报出异常，SQL线程是否会跳过当前的SQL继续往后执行（即使失败了），还是会挂起等待重做？
希望能按情况具体讨论下这个问题....
大盗贼的答案，所说的串行部分是对的。
刚才问了专家，专家表示：
slave上sql执行失败以后，binlog同步不会继续，会停下来，就停在错误的地方。
除非你在my.cnf里配置 slave_skip_errors 调过错误。
会发生不一致，因为Binlog的不是串行的~~
建议把从库binlog版本拉回到出错以前，让它慢慢恢复
-- 更新 --
上边说的有点歧义~~~
首先发生不一致是肯定的。
Binlog从master到slave的过程是串行，即使master上有并行SQL，也会做串行化，然后一条一条的发到slave。如果slave上出现了锁表什么的，把某条master过来的sql阻塞了，那么后边的会等。如果slave的网断了，那master会一次一次的重试，直到连上了，继续发。这两种情况不会发生不一致。
但你问题里说道的，是slave上出了问题，也就是说，master把binlog发给slave，slave执行，但失败了。这种情况不会阻塞binlog的同步。
你可以在slave上
看一下情况，看看binlog的位置，就知道是否会出现不一致的情况