MySQL Binlog文件损坏处理一则

                                  MySQL Binlog文件损坏处理一则

   Mysql binlog用来记录在服务器端上执行的SQL语句（假设binlog_format=statement).
根据sync_binlog的设置(默认为0,可以设置为1),当设置为0时，每次线程在生成binlog时
不调用操作系统同步文件的函数，这样binlog可能存在于文件系统缓存中.设置为1时，每次
在写binlog时，同时设用操作系统同步文件系统的函数，保证binlog会写到文件系统中.

   设置为1时，每次都需要同步文件系统，再加上使用innodb存储引擎，本身又有自己的事务
日志，从而给IO带来很大的压力.当设置为0时，带来的好处是事务处理性能基本上不受到binlog的影响,
但是安全性受到影响,比如在掉电时，binlog没有及时写回，导致了binlog损坏，从而使mysql无法正常
启动.

..........................
 2014-08-26 09:37:08 12507 [Note] InnoDB: 128 rollback segment(s) are active.
2014-08-26 09:37:08 12507 [Note] InnoDB: Waiting for purge to start
2014-08-26 09:37:08 12507 [Note] InnoDB:  Percona XtraDB () 5.6.14-rel62.0 started; log sequence number 1759775
/usr/local/Percona-Server-5.6.14-rel62.0-483.Linux.x86_64/bin/mysqld: The binary log file './1.000005' is logically corrupted: The first global transaction identifier was read, but no other information regarding identifiers existing on the previous log files was found.
2014-08-26 09:37:08 12507 [ERROR] Aborting

2014-08-26 09:37:08 12507 [Note] Binlog end
2014-08-26 09:37:08 12507 [Note] Shutting down plugin 'partition

..........................

可以看到binlog已经逻辑上损坏了

如果这时候有从库的话，可能会存在问题，比如从库还没有来得及把主库的binlog挖过去.

临时的解决办法就是修改log_bin设置，从新指定一个名字，启动mysql服务器.原来的从库可能需要重初始化.

有时候sync_binlog带来的io压力又很大，设置为0或是1确实是一个问题.在mysql 5.6以后引入了rpl-semisync后
，设置sync_binlog.使用这种方式带来可选的方案。前提是要到从库的网络，性能要够快，而不致于对主库的事务响应
时间带来延迟.

mysql还有几个文件都有这种和文件缓存的问题，在5.6以后版本中，引入了设置同步的参数,可以从一定程序上避免这种
问题的发生，但是有性能影响，由用户自行选择.

mysql> show global variables like 'sync_%';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| sync_binlog         | 0     |
| sync_frm            | ON    |
| sync_master_info    | 10000 |
| sync_relay_log      | 10000 |
| sync_relay_log_info | 10000 |
+---------------------+-------+
5 rows in set (0.00 sec)