mysql--二进制日志(bin-log)

一、设置二进制日志　　
　　进制日志记录了所有的DDL和DML，但不包括各种查询。通过二进制日志，可以实现什么效果呢？二进制日志文件可以【实现灾难数据恢复】，另外可以应用到【mysql复制数据同步】。二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述了数据更改。运行服务器时若启用二进制日志则性能大约慢1%。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。

　　–log-bin[=file_name]  选项启动该日志类型，mysqld写入包含所有更新数据的SQL命令的日志文件。
　　如果未给出file_name值，默认名为“HOSTNAME-bin.nnnnn”；如果给出了文件名，但没有包含路径，则文件被写入数据目录。如果在日志名中提供了扩展名(例如，–log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。二进制日志文件名的.nnnn表示，mysqld在每个二进制日志名后面添加一个数字扩展名。每次启动服务器或刷新日志（flush logs）时该数字增加1。如果当前的日志大小达到设定的max_binlog_size，还会自动创建新的二进制日志。如果在该文件的末尾正使用大的事务，二进制日志可能会超过max_binlog_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

　　–binlog-do-db=db_name  告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，应将更新记录到二进制日志中。其它所有没有明显指定的数据库被忽略。
　　如果数据库启动时使用选项–binlog-do-db=DB_A，使用语句“use DB_B”置DB_B为当前数据库，此时使用update语句修改DB_A的表数据时出现如下情况：
　　　　数据库DB_B不在允许binlog的列表内，该语句不写入二进制日志文件
　　　　数据库DB_B在允许binlog的列表内，该语句写入二进制日志文件

　　–binlog-ignore-db=db_name  告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，不将更新保存到二进制日志中。

综上所述，使用这个两个选项时决定是否将该语句写入日志文件还有参考当前数据库的属性，如果指定了这两个选项尽量使指定的数据库为当前数据库，才能按照逻辑来记录日志。但CREATE DATABASE、ALTER DATABASE和DROP DATABASE等语句，有一个例外，即通过操作的数据库来决定是否应记录语句。

#vi /etc/my.cnf
　　log-bin[=/usr/local/mysql/var/mysql-bin]     //启用二进制日志功能；如果该设置没带路径，就放在datadir=/var/lib/mysql 下
　　binlog-do-db[=数据库名]                      //指定记录二进制日志的数据库
　　binlog-ingore-db[=数据库名]                  //指定不记录二进制日志的数据库

二、查看二进制日志文件
1、由于binlog以是binary方式存取，不能直接查看，需要用mysql提供的mysqlbinlog工具查看。
mysqlbinlog命令
格式:mysqlbinlog [选项]  日志文件
  选项: -d 数据库名   　　　　　　 列出指定数据库的二进制日志
         -h 服务器地址  　　　　　　指定数据库服务器地址
         -u 用户名      　　　　　　  指定连接服务器的用户名
         -p 口令       　　　　　　     指定用户口令
         -P 数字       　　　　　　     指定服务器端口号
         -R             　　　　　　　　读取二进制日志
        --start-datetime=datetime  指定开始时间
        --stop-datetime=datetime   指定结束时间
         --start-position=数字          指定开始位置
         --stop-position=数字          指定结束位置

实例:-查看本机mysql服务器的binlog.001二进制日志文件内容
      [root@localhost ~]mysqlbinlog  binlog.001

2、基本操作
1.到数据库查看是否开启binary log 功能：
　　mysql> show variables like 'log_bin';

2.查看当前工作的日志名及大小：
　　mysql> show binary/master logs;

3.清除所有binary logs,新日志重新从000001开始编号:
　　mysql> reset master;

4.清除指定部分logs：
　　mysql>purge binary logs to 'log-bin.000012';  　　　　　　 //将log-bin.000012之前的binary logs清掉；
　　mysql>purge binary logs before '2011-05-28 12:05:38';   //将指定时间之前的binary logs清掉；

5.查看当前binary log的情况：
　　mysql>show master status;

6.查看binary logs的内容：
　　mysql>show binlog events\G;    //或指定日志文件查看show binlog events in 'mysql-bin.000001';

7.在my.cnf/my.ini中设定binary logs回滚天数：
　　expire_logs_days = 7    //此参数设置了binlog日志的过期天数

注：删除所有二进制日志
a.如果没有主从复制，可以通过reset master的方式，重置数据库日志，清除之前的日志文件：
     mysql>reset master; 　　#重新开始

b.但是如果存在复制关系，应当通过PURGE的方式来清理bin日志：
语法如下：
    PURGE {MASTER | BINARY} LOGS TO 'log_name'    　　//基于位置的恢复
    PURGE {MASTER | BINARY} LOGS BEFORE 'date'   　　 //基于时间点的恢复      MASTER和BINARY是同义词。

由于删除指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除，这样被给定的日志成为第一个。
例如：
    PURGE MASTER LOGS TO 'mysql-bin.010';          　　　　 //删除 mysql-bin.001--mysql-bin.009之间文件，mysql-bin.010会成为日志的第一个
    PURGE MASTER LOGS BEFORE '2008-06-23 15:00:00';    //清除3天前的 binlog，BEFORE变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。
 
注:如果您有一个活性的从属服务器，该服务器当前正在读取您正在试图删除的日志之一，则本语句不会起作用，而是会失败，并伴随一个错误。
    不过，如果从属服务器是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。

要清理日志，需按照以下步骤：
   　1. 在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志。
   　2. 使用SHOW MASTER LOGS获得主服务器上的一系列日志。
   　3. 在所有的从属服务器中判定最早的日志。这个是目标日志。如果所有的从属服务器是更新的，这是清单上的最后一个日志。
   　4. 制作您将要删除的所有日志的备份。（这个步骤是自选的，但是建议采用。）
   　5. 清理所有的日志，但是不包括目标日志,因为从服务器还要跟它同步

三、mysql二进制日志灾难恢复
 bin-log是记录着mysql所有事件的操作，可以通过bin-log做完整恢复，基于时间点的恢复，和基于位置的恢复。

1.完整恢复，先执行上次完整备份恢复，再执行自上次备份后产生的二进制日志文件恢复
　　# mysql -h localhost mysql-bin.000001 | mysql -uroot -p
这样数据库就可以完全的恢复到崩溃前的完全状态

2.基于时间点的恢复
a.如果确认误操作时间点为2015-06-04 10:00:00执行如下
　　# mysqlbinlog --stop-date='2015-06-04 9:59:59' mysql-bin.000001 | mysql -uroot -p
  然后跳过误操作的时间点，继续执行后面的binlog
　　# mysqlbinlog --start-date='2015-06-04 10:01:00' mysql-bin.000001 | mysql -uroot -p
  其中--stop-date='2015-06-04 9:59:59' 和 --start-date='2015-06-04 10:01:00'
b.取两时间点
　　# mysqlbinlog --start-datetime="2015-07-02 11:25:56" --stop-datetime="2015-07-02 14:20:10" mysql-bin.000001 | mysql -u root -p
    #注：其中的时间是你误操作的时间，而且这个时间点还可能涉及到的不只是误操作，也有可能有正确的操作也被跳过去了。那么执行位置恢复。

3.基于位置恢复，通过查看日志文件信息，确认6259-6362为误操作点
　　# mysqlbinlog --stop-position=6259 mysql-bin.000001 | mysql -uroot -p　　　　 #从1开始至6259的事件读，不包括6259事件
　　# mysqlbinlog --start-position=6363 mysql-bin.000001 | mysql -uroot -p 　　　　#从6259的事件开始读
　　# 取两事件点
　　mysqlbinlog --start-position=5786 --stop-position=6254 mysql-bin.000001 | mysql -uroot -p