MySQL复制 -- Binlog (1)

复制之所以工作得益于MySQL把对数据库的变更都记录在 binlog中，然后主库把它读出来，放到从库上去应用。当然binlog 的用途不仅限于此，比如 PITR等

在5.1.4版本以前，binlog格式只能是 statement -based replication ,在以后的版本中引入了 row-based replication 以及 mixed-based replication。

下面我会简单的介绍一下SBR、RBR、MBR 这三种格式下binlog是如何组织的，更重要的是在这三种格式下，replication是如何进行工作的。当然我主要介绍 RBR模式下的复制，因为RBR模式下我们的复制是认为是最安全的方式，即使是使用MBR也会有可能踩到坑。

在MySQL中，Binlog有两类文件，一类文件用于记录数据变更，一类文件用于记录binlog list。

Binlog list文件就是 ${HOSTNAME}-bin.index  ；用于记录当前有哪些binlog

binlog的数据文件名字类似于 ${HOSTNAME}-bin.00001,这类文件是我们重点关注的对象。

先来大概的看看binlog 的文件内容：

svan-mac:mydata xiean$ mysqlbinlog -vvvv mysql-bin.000010

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#151218 15:19:30 server id 5331  end_log_pos 123 CRC32 0xd483743a         Start: binlog v 4, server v 5.7.9-log created 151218 15:19:30

# Warning: this binlog is either in use or was not closed properly.

BINLOG '

grNzVg/TFAAAdwAAAHsAAAABAAQANS43LjktbG9nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA

ATp0g9Q=

'/*!*/;

# at 123

#151218 15:19:30 server id 5331  end_log_pos 154 CRC32 0x622c3733         Previous-GTIDs

# [empty]

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

DELIMITER ;

# End of log file

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

抽一段binlog出来看看：

# at 141

#151218 15:19:30    server id 5331      end_log_pos 245

Query thread_id=3350  exec_time=11  error_code=0

at 141	当前事件在文件中的起始位置，单位bytes
#151218 15:19:30	当前事件开始时间
Server id	当前事件在哪个Server 执行的
End_log_pos	下一个事件在文件中的开始位置，即当前事件内容为  4~end_log_pos-1范围
exec_time	执行所花费的时间(如果是Master )；
error_code	执行该事件时的结果

我们把Binlog 文件拆分成3个部份

简单描述 －－>

{

"header": "desc …",
    "event": "xxxxxxx",
    "footer": "log rotat"
}

第一部份： 由 4-bytes 开始，这4-bytes 表明它是一个MySQL binlog 文件（由log_event.h 这个文件常量：BINLOG_MAGIC (0xfe 0x62 0x69 0x6e = 0xfe 'b''i''n') 表示），这也就能解释我们的第一个event 为什么 起始位置是 4 了原因了。

第二部份： 一个一个的 event ，每个event 根据binlog版本不同，解释出来的含义有所不同(在MySQL 5.0＋ binlog版本都使用的是 V4版本)

第三部份：也就是文件最后event用于记录log-rotation 事件，表明了接下来的日志将写入哪个文件。

Event 是binlog 记录的最小单位，event 的上一级是event group ，复制或者恢复的时候基于 event group 来重放日志。对于一个组来说，要么都执行， 要么都不执行。而对于DML来说一个 event 包含多个event，而对于DDL 来说，一个event 就是一个 event group。对于每个Event里边有哪些东西，以及event group 是如何划分的我们将在下面讨论。

触发器，存储过程，函数在MySQL里边是如何处理的呢？

触发器，存储过程，函数 在创建的时候都会记录Binlog

触发器在执行的时候 Master、Slave 都会被调用，Master上的触发器将会在Master上被调用，Slave上的触发器将会在Slave上被调用。

存储过程在执行的时候，Master上会被转化成具体的SQL语句存储在Binlog里边，因此在binlog里边是看不到任何 call 来调用存储过程的event 。

函数在执行的时候并不会被解析成为具体的语句，相反函数执行时和触发器比较相像，在Master上和Slave都会被调用。

三种模式下Binlog 是如何记录的

基于语句的复制 ： 是MySQL 5.7.7 版本以前默认配置，它将SQL语句（而不是实际的数据变化）从主服务器复制到从服务器。

优点 ：在某些情况下，最终写入日志文件的数据更少，例如更新或者删除许多行时。对于只影响几行数据的简单语句，基于行的复制占用的空间更少。

缺点 ： 最明显的是它不支持不确定性的语句，例如当前时间函数。

基于行的复制 ： 使用单个的表行记录变化，而不是语句。主服务器将消息，也就是事件写入二进制日志，表示单个表行的变化。这与其他RDBMS中更加传统的复制方式类似。

优点：需要更少的锁定，意味着能够达到更高的并发。

缺点：它会产生更多需要记录的数据，占用的空间大。

混合模式日志 ： 可以根据要记录的事件实时改变二进制日志格式。使用混合模式复制时，默认采用基于语句的复制，但是在某些情况下自动切换到基于行的复制

PPT下载地址：http://pan.baidu.com/s/1mgZrvLI