这个报错网上搜索了一下，大部分是由于MySQL意外关闭或强制重启造成的binlog文件事务点读取异常造成的主从同步报错
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the last event was read from '/mysqlLog/aldb2/logs/mysql-bin.000105' at 112415826, the last byte read was read from '/mysqlLog/aldb2/logs/mysql-bin.000105' at 112415845.'
网上有对这种问题进行的解释：
http://www.itpub.net/thread-1778154-1-1.html
1）就是主库的主机宕机了，从库再次启动时，出现错误，这个在sync_binlog=0的情况，很容易出现。
原因： sync_binlog=0时 ，master binlog文件的flush log buffer（这个buffer是由于binlog文件的os buffer) 到disk是依赖于OS本身的，但Slave IO 线程在读取master dump 线程的位置，一般是直接读取log buffer的,
这个位置，可能远远大于，binlog文件实际大小。 所以当主机宕机后，binlog buffer未刷盘，当Master主机再次启动后，此时从库的binlog pos已经比实际的binlog文件大小还大了。
处理方法：如果innodb_flush_log_at_trx_commint=1的话，这一般对主从不会有影响的，直接做change master to到当下一个binlog。
如果是其他值2或0，可能有点小差别。
有人说重新change就可以，我通过mysqlbinlog 查看报错时的binlog文件最后的几个事务，也尝试change最后几个事务的点，但未成功。
后来按照一个网友的方法
1、flush log;
2、show master status \G
3、change master on 'master新binlog文件'
问题解决，但最后mysqlbinlog检查主库上一个binlog文件最后的几个事务是否完成，保证数据一致
这个对于MySQL5.5的半同步复制进行的说明也不错：
http://wubolu.iteye.com/blog/721131