mysql binlog

mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。
如果当前的日志大小达到max_binlog_size，还会自动创建新的二进制日志。如果你正使用大的事务，
二进制日志还会超过max_binlog_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

my.ini中有两个设置：
#expire_logs_days = 10
#max_binlog_size = 100M

Expire_logs_days :定义了mysql清除过期日志的时间。
二进制日志自动删除的天数。默认值为0,表示“没有自动删除”。启动时和二进制日志循环时可能删除。
max_binlog_size
如果二进制日志写入的内容超出给定值，日志就会发生滚动。你不能将该变量设置为大于1GB或小于4096字节。 默认值是1GB。

====
随着mysql的运行，其binlog日志会越来越多，占用的磁盘会越来越大。
我们需要定期清理这些过期的binlog日志。
处理方法主要有两种：
1、自动删除
2、手动删除


1、自动删除
需要更改其配置文件my.cnf，添加参数expire_logs_days = 10，单位是天。
2、手工删除
当然我们可以手动删除binlog日志文件，但是这样并不会更新
mysql-bin.index
我们可以利用mysqlbinlog删除工具purge来删除并更新。
查看帮助：
mysql>help purge;
Name: 'PURGE BINARY LOGS' Description: Syntax:
PURGE { BINARY | MASTER } LOGS { TO 'log_name' | BEFORE datetime_expr }

Examples: PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';

mysql>purge binary logs before '***';

这样我们就可以删除一些特定的binlog日志。


===
自动清理MySQL binlog日志与手动删除的设置 (2010-11-19 11:28:38)转载▼
标签： mysql binlog 杂谈 分类： 工作日志
我们大家都知道MySQL数据库从复制(replication)采用了RBR 模式之后，binlog 的格式为"ROW"，其主要作用是解决很多原先出现的主键重复问题。
在一个繁忙的master db server上，MySQL binlog日志文件增长速度很快，如果不定时清除，硬盘空间很快就会被充满。
设置自动清理MySQL binlog日志，配置my.cnf：
expire_logs_days = 10
在运行时修改：

show binary logs; 
show variables like '%log%'; 
set global expire_logs_days = 10;

清除之前可以采用相应的备份策略。
手动删除10天前的MySQL binlog日志：
PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);
show master logs;
////////////////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       143 |
| mysql-bin.000002 |   7183278 |
+------------------+-----------+
2 rows in set (0.00 sec)
mysql> purge binary logs before date_sub(current_date,interval 1 day);  --删除一天以前的，貌似没多大用
Query OK, 0 rows affected (0.00 sec)

mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       143 |
| mysql-bin.000002 |   7258953 |
+------------------+-----------+
2 rows in set (0.00 sec)
不知道从库能不能删除一些日志：
mysql> purge binary logs before date_sub(current_date,interval 1 day);
Query OK, 0 rows affected (0.00 sec)  --清楚无任何效果


MASTER和BINARY是同义词。
一般情况下，推荐使用MIXED binlog的复制。http://dev.MySQL.com/doc/refman/5.1/en/open-bugs-general.html中 的
说明:Replication uses query-level logging: The master writes the executed queries to the
binary logThis is a very fast, compact, and efficient logging method that works perfectly in most cases
附：关于MySQL复制的几种模式

从 MySQL 5.1.12 开始，可以用以下三种模式来实现：
基于SQL语句的复制(statement-based replication, SBR)，
基于行的复制(row-based replication, RBR)，
混合模式复制(mixed-based replication, MBR)。
相应地，binlog的格式也有三种：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默认的。
在运行时可以动态改动 binlog的格式，除了以下几种情况：
存储流程或者触发器中间
启用了NDB
当前会话试用 RBR 模式，并且已打开了临时表
如果binlog采用了 MIXED 模式，那么在以下几种情况下会自动将MySQL binlog的模式由 SBR 模式改成 RBR 模式。
当DML语句更新一个NDB表时
当函数中包含 UUID() 时
2个及以上包含 AUTO_INCREMENT 字段的表被更新时
行任何 INSERT DELAYED 语句时
用 UDF 时
视图中必须要求运用 RBR 时，例如建立视图是运用了 UUID() 函数
设定主从复制模式：
log-bin=MySQL-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"

也可以在运行时动态修改binlog的格式。例如
MySQL> SET SESSION binlog_format = 'STATEMENT';
MySQL> SET SESSION binlog_format = 'ROW';
MySQL> SET SESSION binlog_format = 'MIXED';
MySQL> SET GLOBAL binlog_format = 'STATEMENT';
MySQL> SET GLOBAL binlog_format = 'ROW';
MySQL> SET GLOBAL binlog_format = 'MIXED';
两种模式各自的优缺点：
SBR 的优点：
历史悠久，技能成熟
binlog文件较小
binlog中包含了所有数据库修改信息，可以据此来审核数据库的安全等情况
MySQL binlog可以用于实时的还原，而不仅仅用于复制
主从版本可以不一样，从服务器版本可以比主服务器版本高
SBR 的缺点：
不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
调用具有不确定因素的 UDF 时复制也可能出疑问
运用以下函数的语句也不能被复制：
LOAD_FILE()
UUID()
USER()
FOUND_ROWS()
SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
INSERT … SELECT 会产生比 RBR 更多的行级锁
复制须要执行 全表扫描(WHERE 语句中没有运用到索引)的 UPDATE 时，须要比 RBR 请求更多的行级锁
对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句
对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响
存储函数(不是存储流程 )在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事
确定了的 UDF 也须要在从服务器上执行
数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错
执行复杂语句如果出错的话，会消耗更多资源
RBR 的优点：
任何情况都可以被复制，这对复制来说是最安全可靠的
和其他大多数数据库系统的复制技能一样
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
复制以下几种语句时的行锁更少：
INSERT … SELECT
包含 AUTO_INCREMENT 字段的 INSERT
没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
执行 INSERT，UPDATE，DELETE 语句时锁更少
从服务器上采用多线程来执行复制成为可能
RBR 的缺点：
binlog 大了很多
复杂的回滚时 binlog 中会包含大量的数据
主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写疑问
UDF 产生的大 BLOB 值会导致复制变慢
不能从 binlog 中看到都复制了写什么语句(加密过的)
当在非事务表上执行一段堆积的SQL语句时，最好采用 SBR 模式，否则很容易导致主从服务器的数据不一致情况发生
另外，针对系统库 MySQL 里面的表发生变化时的处理准则如下：
如果是采用 INSERT，UPDATE，DELETE 直接操作表的情况，则日志格式根据 MySQL binlog_format 的设定而记录
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何 都采用 SBR 模式记录。
注：采用 RBR 模式后，能处理很多原先出现的主键重复问题。实例:
对于insert into db_allot_ids select from db_allot_ids 这个语句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG日志信息为:


BEGIN  ;  # at 173  #090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0 SET TIMESTAMP=1244793942;  insert into db_allot_ids select * from db_allot_ids  ;
在BINLOG_FORMAT=ROW 模式下:


====
mysqladmin flush-logs 也可以重新开始新的binary log


=====
解决方法如下：

第一种方法：

mysql> show binary logs;  查看mysql bin-log日志，除了这个以外的，其它都可以使用删除。

mysql> purge binary logs to 'binlog.000058';  （删除mysql bin-log日志，删除binlog.000005之前的，不包括binlog.000058）

第二种方法：

进入数据库，查看一下当前使用的binlog日志是哪个，除了这个以外的，其它都可以使用rm -rf 删除！



=====
查看指定删除日志
mysql >show binary logs; 查看多少binlog日志，占用多少空间。
mysql> PURGE MASTER LOGS TO 'mysql-bin.002467'; 删除mysql-bin.002467以前所有binlog，
这样删除可以保证*.index信息与binlog文件同步。


手动清理
mysql>PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 5 DAY); 手动删除5天前的binlog日志


自动设置清理
mysql> set global expire_logs_days = 5; 把binlog的过期时间设置为5天;
mysql> flush logs; 刷一下log使上面的设置生效，否则不生效。

为保证在MYSQL重启后仍然有效，在my.cnf中也加入此参数设置
expire_logs_days = 5





==================================实际操作==========
mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       143 |
| mysql-bin.000002 |  12180875 |
+------------------+-----------+
2 rows in set (0.01 sec)

mysql> purge binary logs before date_sub(current_date,interval 2 day);
Query OK, 0 rows affected, 1 warning (0.05 sec)

mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000002 |  12244804 |
+------------------+-----------+
1 row in set (0.00 sec)




///////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
使用binlog恢复数据的重要命令如下
mysql> flush logs;  默认的日志是mysql-bin.000001，现在刷新了重新开启一个就多了一个mysql-bin.000002
                                ./mysqlbinlog --no-defaults binlog日志名，来查看日志
[root@localhost bin]# ./mysqlbinlog --no-defaults ../var/mysql-bin.000001 | more    //查看bin-log日志的内容
[root@localhost bin]# ./mysqlbinlog --no-defaults ../var/mysql-bin.000001 | ./mysql -uroot -p //恢复mysql-bin.000001日志的内容
如果需要从某个点恢复到某个点，用以下操作
定位： --start-position 开始点
--stop-position 结束点
--start-date 开始时间
--stop-date  结束时间
现在恢复mysql-bin.000002恢复，从134点开始到386结束 
[root@localhost bin]# ./mysqlbinlog --no-defaults --start-position 134 --stop-position=386 ../var/mysql-bin.000002 | ./mysql -uroot -p

/**        mysqlbinlog日志恢复数据实验        ****/
//查看一下var下面的内容，现在是没有mysql-log.000001类似的binlog日志的
[root@localhost var]# ls
brocms      ibdata1      ib_logfile1    localhost.pid  mysql-bin.index
brotherblog  ib_logfile0  localhost.err  mysql          test
[root@localhost var]# ../bin/mysql -uroot -p //登录数据库
mysql> use test; //使用test数据库
mysql> flush logs; //刷新binlog日志，新开一个，现在会在var目录下面生成一个mysql-bin.000001的文件，以下的操作都会记录其中

//创建一个表
mysql> create table user(
    -> id int auto_increment primary key,
    -> username char(30),
    -> password char(32))
    -> engine=myisam default charset=utf8;
//插入几条测试数据
mysql> insert into user(username,password) values(1,2);
mysql> insert into user(username,password) values(1,2);
mysql> insert into user(username,password) values(1,2);
//新开一个binlog日志，现在会生成一个名为mysql-bin.000002的文件,下面的操作会记录在mysql-bin.000002的文件中

mysql> flush logs;
//查询一下内容
mysql> select * from user;
+----+----------+----------+
| id | username | password |
+----+----------+----------+
|  1 | 1        | 2        |
|  2 | 1        | 2        |
|  3 | 1        | 2        |
+----+----------+----------+
mysql> delete from user; //现在将数据删除
mysql> drop table user; //将表删除
mysql> select * from user; //查看表里面的内容
mysql> \q
[root@localhost var]# ls
brocms      ibdata1      ib_logfile1    localhost.pid  mysql-bin.000001  mysql-bin.index
brotherblog  ib_logfile0  localhost.err  mysql          mysql-bin.000002  test
[root@localhost var]# ../bin/mysqlbinlog --no-defaults mysql-bin.000001 | more //查看mysql-bin.000001里面的内容
[root@localhost var]# ../bin/mysqlbinlog --no-defaults mysql-bin.000002 | more //查看mysql-bin.000002里面的内容
[root@localhost var]# ../bin/mysqlbinlog --no-defaults mysql-bin.000001 | ../bin/mysql -uroot -p //用mysql-bin.000001来恢复数据
Enter password:
[root@localhost var]# ../bin/mysql -uroot -p //进数据库查看
mysql> use test;
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| user          |
+----------------+
1 row in set (0.00 sec)

mysql> select * from user; //查看数据，数据回来了
+----+----------+----------+
| id | username | password |
+----+----------+----------+
|  1 | 1        | 2        |
|  2 | 1        | 2        |
|  3 | 1        | 2        |
+----+----------+----------+
3 rows in set (0.00 sec)

mysql> \q
如果需要从某个点恢复到某个点，用以下操作
定位： --start-position 开始点
--stop-position 结束点
--start-date 开始时间
--stop-date  结束时间

现在恢复mysql-bin.000002恢复，从134点开始到386结束 
[root@localhost bin]# ./mysqlbinlog --no-defaults --start-position 134 --stop-position=386 ../var/mysql-bin.000002 | ./mysql -uroot -plinux