作为 MySQL 服务器层日志,MySQL binlog 按照事务提交的顺序,记录了所有事件,用户可以通过它完成 point_in_time 的恢复工作,并且 MySQL 的复制也需要它。
默认情况下,binlog 是关闭的,如果要开启,则要在 MySQL 的配置文件中加入:
log-bin=dir/filename // 该配置项开启 binlog 功能,并且指定日志文件存放的路径及文件名。修改之后要重启 MySQL 服务器。
可以使用 SHOW VARIABLES LIKE ‘log_bin’; 来查看是否开启了 binlog 。
binlog 的格式
MySQL 可以以不同的格式来记录主库上成功执行了的事件,不同的格式的 binlog 又会影响 MySQL 的复制。
##1. STATEMENT 格式
这种格式是 MySQL 中最早支持的 binlog 格式,这种格式的 binlog 记录的是执行过的 SQL 语句。备库在重放这种格式的 binlog 时,实际上就是把 SQL 语句重新执行一遍(Replication)。
这种格式的 binlog 结构更加紧凑,而且日志文件也小得多。但是基于这种日志的复制会遇到很多问题,比如遇到一些非确定事件(比如使用了 uuid()、rand() 等函数,以及触发器等),不能保证主备一致性。注意,触发器、函数、存储过程都会在从库相应地执行一遍,因此从库也要有它们的定义。
##2. ROW 格式
这种格式的 binlog 记录的是对行所做的实际修改,是实际的数据。备库上不再是通过执行 SQL 语句,而是以一种观察不到的方式来重放事件。同时&#