Mysql学习之--Mysql二进制日志管理

Mysql学习之--Mysql二进制日志管理

     MySQL的二进制日志可以说或是MySQL最重要的日志了,它记录了所有的DDL和DML(除了数据查询语句)语句,以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是失误安全型的.
      MySQL的二进制日志的作用是显而易见的，可以方便的备份这些日志以便做数据恢复，也可以作为主从复制的同步文件，然而二进制日志的大小可能会根据不同的需求而存在麻烦，所以让日志回滚是必须的，当然MySQL已经为我们提供了二进制回滚的功能，那就是max_binlog_size参数。

       默认MySQL的二进制日志达到1G后就会自动回滚，如果我们想要更小的二进制日志，可以使用max_binlog_size参数来设置。测试使用max_binlog_size=200M，具体应用就是在配置文件里添加这个参数max_binlog_size=200M，官方文档是这样解释的：

        mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到 max_binlog_size，还会自动创建新的二进制日志。如果你正使用大的事务，二进制日志还会超过 max_binlog_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。也就是说，在达到max_binlog_size的时候，如果正在处理一个大的事务，那么二进制日志会在处理完这个事务后才会回滚，所以该二进制日志可能会大于所设定的max_binlog_size。

         在主从复制的应用中，可能我们不希望二进制日志过大，因为日志过大可能会影响日志的执行效率，适当调整max_binlog_size的值还是非常有意义的，当然还要记得定期清理长时间不用的日志哦，要不然你的硬盘空间很快就会被用完的。

删除全部二进制日志：

修改my.cnf
完全恢复：
如果误删了一张表，使用完全恢复是没有用的，因为日志里同样也保留着删除的sql语句，所以我们需要恢复到误操作前的状态，然后跳过误操作的语句。
假如我在20:00误删了一张表，可以使用以下语句恢复：
基于位置点的恢复可以得到更为精确的数据。

如上图，drop table test这条语句的起始位置是889107，终止位置是889189，那么我们可以使用于以下语句进行恢复：
mysqlbinlog --stop-position=‘889107‘ /var/lib/mysql/mysql-bin.000001|mysql -uroot -p
mysqlbinlog --start-position=‘889189‘ /var/lib/mysql/mysql-bin.000001|mysql -uroot -p
有时有可能因为系统版本的问题，以上方法行不通，可以将二进制导出到一个sql文件中，再直接根据sql语句进行恢复
mysqlbinlog  mysqlbinlog.000001 >log.sql
完全恢复案例：
mysql> select * from test2;
+------+-------+
| id   | name  |
+------+-------+
|   10 | tom   |
|   20 | jerry |

恢复以前的数据：
[root@ogg mysql]# mysqlbinlog  /var/lib/mysql/mysql-bin.000003|mysql -uroot -poracle

恢复后查询： 
mysql> select * from test2;
+------+-------+
| id   | name  |
+------+-------+
|   10 | tom   |
|   20 | jerry |
|   60 | jack  |
|   60 | jack  |
|   60 | jack  |
|   60 | jack  |
|   60 | jack  |
|   50 | john  |
|   40 | ellen |
|   30 | rose  |
+------+-------+
10 rows in set (0.00 sec)
Binlog_format参数也特别重要。从mysql5.1版本开始引入这个参数，该参数可以设置的值有STATEMENT、ROW、MIXED；
（1）STATEMENT格式和之前的mysql版本一样，二进制日志文件记录的是日志的逻辑失SQL语句。
（2）在ROW格式下，二进制日志记录的不再是简单的SQL语句了，而是记录表的行更改情况，此时可以将InnoDB的事务隔离基本设为READ COMMITTED，以获得更好的并发性。
（3）MIXED格式下，mysql默认采用的STATEMENT格式进行二进制日志文件的记录，但是在一些情况下会使用ROW格式，可能的情况包括：
1）表的存储引擎为NDB，这时对于表的DML操作都会以ROW格式记录
2）使用了UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT()等不确定函数
3）使用了INSERT DELAY语句
4）使用了用户定义函数
5）使用了临时表
binary log相关变量和参数
命令行参数
  --log-bin [=file_name]
  设置此参数表示启用binlog功能，并制定路径名称。
  --log-bin-index[=file]
  设置此参数是指定二进制索引文件的路径与名称。
  --max_binlog_size
 Binlog最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，
为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束。
  --binlog-do-db=db_name
  此参数表示只记录指定数据库的二进制日志
  --binlog-ignore-db=db_name
  此参数表示不记录指定的数据库的二进制日志
系统变量
  log_bin
  binlog_cache_size
  此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。
  max_binlog_cache_size
  此参数表示binlog使用的内存最大的尺寸
  binlog_cache_use
  使用二进制日志缓存的事务数量
  binlog_cache_disk_use
  使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量。
  binlog_do_db
  binlog_ignore_db
  sync_binlog
  这个参数直接影响mysql的性能和完整性。
  sync_binlog=0：
  当事务提交后，Mysql仅仅是将binlog_cache中的数据写入binlog文件，但不执行fsync之类的磁盘，同步指令通知文件系统将缓存刷新到磁盘，而让Filesystem自行决定什么时候来做同步，这个是性能最好的。
  sync_binlog=0，在进行n次事务提交以后，Mysql将执行一次fsync之类的磁盘同步指令，通知文件系统将Binlog文件缓存刷新到磁盘。
  Mysql中默认的设置是sync_binlog=0，即不做任何强制性的磁盘刷新指令，这时性能是最好的，但风险也是最大的。一旦系统Crash，在文件系统缓存中的所有Binlog信息都会丢失。



本文出自 “” 博客，请务必保留此出处