一,错误日志

1,错误日志文件对Mysql的启动,运行,关闭过程进行了记录。默认名是:机器名.err

Windows下db2数据库归档日志清理_日志文件

当Mysql不能正常启动时,我们应该查看该错误日志文件。

Windows下db2数据库归档日志清理_归档日志_02

 

2,在配置文件中,我们可以修改错误日志的文件名

  log_error = mysql.err

 二,慢查询日志

我们可以设置一个阈值,把运行时间超过该值的所有SQL语句都记录到慢查询日志文件中。

默认情况下,Mysql数据库并不启动慢查询日志,我们可以在配置文件中,手动设置。

相关参数:



slow_query_log:是否开启慢查询日志
slow_query_log_file:慢查询日志文件名
long_query_time:指定慢查询阈值
min_examined_row_limit:扫描记录少于该值的sql不记录到慢查询 日志
log_queries_not_using_index:将没有使用索引的sql记录到日志
log_throttle_queries_not_using_indexes:限制每分钟记录没有使用索引的sql语句的次数
long_slow_admin_statement:记录管理操作,如alter table
log_output:慢查询日志格式,可以输出到表或文件中。如: file|table  文件|表。
log_slow_slave_statements:在从服务器上开启慢查询日志
log_timestamps:写入时区信息



Windows下db2数据库归档日志清理_数据库_03

 三,查询日志

记录所有对Mysql数据库请求的信息,默认文件名:主机名.log。还可以把记录放在mysql库下的general_log表中。

四,归档日志(binlog)

记录对数据库执行更改的所有操作,但是不包括select和show这类操作。默认情况下归档日志文件并没有启动

1,归档日志的作用:

恢复:做数据恢复时,可以通过归档日志进行point-in-time的恢复

复制:通过执行归档日志使得从库和主库进行实时同步

2,归档日志相关配置

max_binglog_size:单个归档日志文件的最大值,超过该值,就产生新的归档日志文件(后缀名+1)

binlog_cache_size:归档日志缓存大小,默认32K

sync_binlog:表示每写缓冲多少次就同步到磁盘,如果设置为1,表示采用同步写磁盘的方式来写归档日志,就不使用缓存了,直接写到文件中

binlog_format:[STATEMENT | ROW | MIXED],

STATEMENT记录的是sql语句。比如:update t2 set username = upper(username) where id = 1

ROW记录的行更改的情况,记两条,更新前和更新后的都记录。

3,当时用InnoDB存储引擎时,所有未提交的归档日志会被记录到一个缓存中。

事务提交后,再把缓存中的归档日志写入文件中。所以,归档日志并不是每次写的时候都同步到磁盘。

五,重做日志(redo log)

1,默认情况下会有两个文件,分别为ib_logfile0和ib_logfile1。

Windows下db2数据库归档日志清理_运维_04

每个InnoDB存储引擎至少有一个重做日志文件组,每个文件组下至少有2个重做日志文件,比如默认:ib_logfile0,ib_logfile1。

日志组中每个重做日志文件的大小一致,以循环的方式使用。

Windows下db2数据库归档日志清理_慢查询_05

 

2,参数配置

innodb_log_file_size:重做日志文件大小

innodb_log_files_in_gourp:日志文件组中重做日志文件的数量,默认为2

inndo_mirrored_groups:日志镜像文件组,默认为1,没有镜像

innodb_log_group_home_dir:日志文件组所在的路径

3,当有一条记录需要更新的时候,InnoDB引擎会先把记录写到redo log里,并更新内存(此时该表的查询缓存失效),这时更新就算完成了。然后 InnoDB引擎会在适当的时候(系统比较闲的时候),把这个操作记录更新到磁盘里。

注意:写入重做日志的操作也不是直接写,而是先写入一个重做日志缓冲中。

Windows下db2数据库归档日志清理_运维_06

 

4,InnoDB的redo log是固定大小的,比如可以配置为一组4个文件,每个文件的大小是1GB,从头开始写,写到末尾就又回到开头循环写。如图:

Windows下db2数据库归档日志清理_归档日志_07

write pos:当前记录的位置,一边写,一边后移。写到第3号文件末尾就回到0号文件开头。

checkpoint:是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件。

Write pos 和 checkpoint之间是空着的部分,用来记录新的操作。如果write pos追上checkpoint,这是后不能在执行新的更新,得先停下来把部分记录更新到数据文件,把checkpoint推进一下。

5,有了redo log,InnoDB可以保证即使数据库发生异常重启,之前的记录都不会丢失,这个能力叫 crash-safe。

六,归档日志和重做日志写入的先后顺序是怎样的?

1, 当执行update语句时,执行器和InnoDB内部的流程:

执行器先找引擎取 ID=2的行,引擎找到这一行然后返回(如果这一行的所在的数据页在内存中,直接返回。否则,从磁盘读到内存,然后返回)

执行器拿到数据,把这个值加1,得到新的一行数据。然后调用引擎接口写入这行新数据

引擎把这行新数据更新到内存中,,同时把这个更新操作记录到redo log中,此时redo log处于 prepare状态。通知执行器随时可以提交事务。

 执行器生成上面加1操作的binlog,并把binlog写入磁盘。

执行器调用引擎的提交事务接口,引擎把刚刚写入的redo log改成提交状态。

Windows下db2数据库归档日志清理_慢查询_08

 

 注意:redo log的写入拆成了两个步骤:prepare和commit,这就是两阶段提交。

2,为什么要有两阶段提交?

2.1, 为了保证两份日志之间的逻辑一致

如果redo log只是完成了prepare,而binlog又失败,那么事务本身会回滚,所以这个库里面的status的值为0.

如果通过binglog恢复出一个库,status的值也是0。这样就不算丢失。

两阶段就是为了保证一致性用的。

2.2,如果不用两阶段提交,通过日志恢复出来的库和数据库的数据可能不一致

比如:先写binlog后写redo log,如果在binlog写完之后crash掉,由于redo log还没写,系统恢复后这个事物无效,所以这一行的值为0.但是binlog里面已经记录了 “把c从0改为1”这个日志。以后用binlog来恢复的时候,恢复出来的这一行c的值就是1,和原库的值不同。