产品中心
purge master logs before 'yyyy-mm-dd hh:mi:ss'将会删除指定日期之前的所有日志。但是若指定的时间处在正在使用中的日志文件中，将无法进行purge。
mysql> show warnings;
+———+——+—————————————————————————+
| Level | Code | Message |
+———+——+—————————————————————————+
| Warning | 1868 | file ./mysql-bin.000003 was not purged because it is the active log file. |
+———+——+—————————————————————————+
3.使用–expire_logs_days=N选项指定过了多少天日志自动过期清空。
在MySQL 5.1之前，MySQL只有一种基于语句statement形式的日志记录格式。即将所有的相关操作记录为SQL语句形式。但是这样的记录方式对某些特殊信息无法同步记录，例如uuid，now()等这样动态变化的值。
从MySQL 5.1开始，MySQL支持statement、row、mixed三种形式的记录方式。row形式是基于行来记录，也就是将相关行的每一列的值都在日志中保存下来，这样的结果会导致日志文件变得非常大，但是保证了动态值的确定性。还有一种mixed形式，表示如何记录日志由MySQL自己来决定。
日志的记录格式由变量binlog_format来指定。其值有：row,statement,mixed。innodb引擎的创始人之一在博客上推荐使用row格式。
下面将记录格式改为row。
查看产生的日志。
BINLOG ‘
gPraWBMBAAAAOgAAAAIBAAAAAF4AAAAAAAEABHRlc3QAB3N0dWRlbnQABAMP/hIFHgD3AQAMCf3N
uA==
gPraWB4BAAAAOAAAADoBAAAAAF4AAAAAAAEAAgAE//AHAAAACXhpYW93b25pdQGZnDqBmCz35ow=
‘;
# at 314
#1703298:06:24 server id 1end_log_pos 345 CRC32 0x7a48c057Xid = 114
COMMIT;
DELIMITER ;
…后面固定部分省略…
发现是一堆看不懂的东西，使用-vv可将这些显示出来。可以看出，结果中记录的非常详细，这也是为什么基于row记录日志会导致日志文件极速变大。
还有一种mixed模式。这种模式下默认会采用statement的方式记录，只有以下几种情况会采用row的形式来记录日志。
1.表的存储引擎为NDB，这时对表的DML操作都会以row的格式记录。
2.使用了uuid()、user()、current_user()、found_rows()、row_count()等不确定函数。但测试发现对now()函数仍会以statement格式记录，而sysdate()函数会以row格式记录。
3.使用了insert delay语句。
4.使用了临时表。
注意：在配置binlog相关变量的时候，相关变量名总是搞混，因为有的是binlog，有的是log_bin，当他们分开的时候，log在前，当它们一起的时候，bin在前。在配置文件中也同样如此。
在innodb的主从复制结构中，如果启用了二进制日志(几乎都会启用)，要保证事务的一致性和持久性的时候，必须将sync_binlog的值设置为1，因为每次事务提交都会写入二进制日志，设置为1就保证了每次事务提交时二进制日志都会写入到磁盘中，从而立即被从服务器复制过去。
只需指定二进制日志的起始位置（可指定终止位置）并将其保存到sql文件中，由mysql命令来载入恢复即可。当然直接通过管道送给mysql命令也可。
至于是基于位置来恢复还是基于时间点来恢复，这两种行为都可以。选择时间点来恢复比较直观些，并且跨日志文件恢复时更方便。
或者将它们导入到一个文件中后恢复。
到此这篇关于MySQL日志的文章就介绍到这了,更多相关MySQL日志分析内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
发表评论