MySQL - binary log

MySQL - binary log

binary log 主要用于记录对MySQL数据库真正执行更改的所有操作即DML语句，不包含那些没有修改任何数据的语句，像 select、show这样的语句就不会被记录；如需记录那么需要开启全量日志功能；

这里介绍全量日志开启的方法：
mysql> show variables like '%general%';
// 查看general log 状态，如下
+------------------+--------------------------------+
| Variable_name    | Value                          |
+------------------+--------------------------------+
| general_log      | OFF                            |
| general_log_file | /data/mysql/VM-0-44-centos.log |
+------------------+--------------------------------+
// 可以看到，目前状态是OFF的

开启方法1 - 永久开启：
// 通过修改配置文件，修改完之后需要重启服务
// 在my.cnf 里的 [mysqld] 添加以下（0-关闭 1-开启）：
general-log = 1
general-log-file = /GENERAL/LOG/PATH
注意：有时候可能重启之后不会生效，可以执行flush privileges再试试；

开启方法2 - 临时开启：
// 临时生效，不用重启；
set global general_log=ON;
set global general_log_file=/GENERAL/LOG/PATH

1. 开启 general log 将所有到达MySQL Server的SQL语句记录下来
2. 一般不会开启此功能，因为log的量会非常庞大；这个日志对于操作频繁的库,产生的数据量会很快增长,出于对硬盘的保护,可以设置其他存放路径；
3. 开启general log 会耗费数据库5%-10%的性能，没有什么特殊需求一般不建议打开；个别情况下可能会临时的开一会儿general log以供排障使用；

两张图：

1. 开启全量日志后
   
2. 查看日志，可以发现记录的很详细
   
   ====================================================================
   ====================================================================

二进制日志的主要作用

1）可以完成主从复制功能：

在主服务器上把所有修改数据的操作记录到binlog中，通过网路发送给从服务器；达到主从同步；

2）进行恢复操作：

数据可以通过binlog日志，使用mysqlbinlog命令，实现基于时间点和位置的恢复操作；

配置参数log-bin=[filename]可以启动二进制日志，如果没有命令filename，那么一般会以主机名来作为二进制日志的文件名；二进制日志文件默认存储在数据目录下；

几个命令总结如下：
show variables like '%log_bin%';			//可以查到一些二进制日志相关参数的value
show binary logs;							//列出当前binlog文件及值得大小
show msater status;							//查看MySQL当前得日志及状态

涉及binlog参数得相关介绍：
show variables like '%max_binlog_size%';	
//该参数制定了单个binlog得最大值，如果超过会自动生成新得binlog文件（重启MySQL实例也会生成新的binlog）
//从MySQL 5.0开始，max_binlog_size 的默认值为 1 GB
show variables like '%binlog_cache%';
//所有未提交的事务会记录到一个缓存中，等待事务提交时，直接将缓存中的二进制日志写入二进制日志文件
//该缓存的大小由binlog_cache_size决定，它的默认大小未32KB，并且binlog_cache_size是基于会话的，也就是当一个线程要开始一个事务时，MySQL会自动分配一个该值大小的缓存

注意：设置binlog_cache_size值要小心，如果设置太小就是使用磁盘上的临时文件来记录；
	 可以通过show global status 命令来查看 binlog_cache_use 和 binlog_cache_dish_use 的使用情况，来判断当前的binlog_cache_size的设置是否合适；
	 show global status like '%binlog_cache%';

binlog_format：二进制日志的格式（三种）

1）row（RBR）

当前日志格式：

update一条语句：

查看日志：二进制日志用head、cat等命令无法查看，需要用mysqlbinlog查看，把日志格式转化后，输出到bin.log文件中：
# mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /data/mysql/binlog.000024 > bin.log
# vim bin.log

参数含义：
-v：具体的执行信息
--base64-output：把二进制日志文件转换格式

可以看到，在row模式下，日志文件格式记录的是基于行的变更情况，会记录变更前以及变更后的内容；

2）statement（SBR）

转换格式后，查看日志：

可以看到 statement 格式下，记录的是完整的sql语句；

3）mixed（MBR）

依旧转换日志格式，然后查看日志：

总结：

1. Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。

优点： 
binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。
所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。
而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题

缺点:
所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容；
比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大；
特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。

2. Statement：每一条会修改数据的sql都会记录在binlog中。

优点：
不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。
(相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，
但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，
因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。)

缺点：
由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同的结果。
另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).

3. Mixedlevel:是以上两种level的混合使用
一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，
则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种；
新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，
像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。

补充：

1.Binlog日志格式选择

由于一些特殊使用，可以考虑使用ROWED；
如自己通过binlog日志来同步数据的修改，这样会节省很多相关操作。
对于binlog数据处理会变得非常轻松,相对mixed，解析也会很轻松
(当然前提是增加的日志量所带来的IO开销在容忍的范围内即可)。 


2.mysqlbinlog格式选择

mysql对于日志格式的选定原则:
如果是采用 INSERT，UPDATE，DELETE 等直接操作表的情况，则日志格式根据 binlog_format 的设定而记录；
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何 都采用 SBR 模式记录


3.Mixed日志说明：

在slave日志同步过程中，对于使用now这样的时间函数，
MIXED日志格式，会在日志中产生对应的unix_timestamp()*1000的时间字符串，
slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。
另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，
则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。