日志管理 MySQL (四)

MySQL 日志管理

1.1 MySQL****日志类型简介

日志的类型的说明:

日志文件 选项 文件名 程序 N/A
表名称
错误 –log-error host_name.err N/A
常规 –general_log host_name.log mysqldumpslow mysqlbinlog
general_log
慢速查询 –slow_query_log –long_query_time host_name-slow.log N/A 程序
slow_log
二进制 –log-bin –expire-logs-days host_name-bin.000001 N/A
审计 –audit_log –audit_log_file audit.log N/A

1.2 配置方法

状态错误日志:

[mysqld]

log-error=/data/mysql/mysql.log

查看配置方式:

mysql> show variables like ‘%log%error%’;

作用:

记录mysql数据库的一般状态信息及报错信息,是我们对于数

据库常规报错处理的常用日志。

mysql> show variables like ‘%log%err%’;

±--------------------±---------------------------------+

| Variable_name | Value |

±--------------------±---------------------------------+

| binlog_error_action | IGNORE_ERROR |

| log_error | /application/mysql/data/db02.err |

±--------------------±---------------------------------+

2 rows in set (0.00 sec)

1.3 一般查询日志

配置方法:

[mysqld]

general_log=on

general_log_file=/data/mysql/server2.log

查看配置方式:

show variables like ‘%gen%’;

作用:

记录mysql所有执行成功的SQL语句信息,可以做审计用,但是我们很少开启

mysql> show variables like ‘%gen%’;

±-----------------±---------------------------------+

| Variable_name | Value |

±-----------------±---------------------------------+

| general_log | OFF |

| general_log_file | /application/mysql/data/db02.log |

±-----------------±---------------------------------+

2 rows in set (0.00 sec)

1.4二进制日志**

二进制日志不依赖与存储引擎的。

依赖于sql层,记录和sql语句相关的信息

binlog****日志作用:

1、提供备份功能

2、进行主从复制

3、基于时间点的任意恢复

记录在sql层已经执行完成的语句,如果是事务,则记录已完成的事务。

功能作用: 时间点备份 和 时间点恢复、 主从

二进制日志的**“总闸”**

作用:

1、是否开启

2、二进制日志路径/data/mysql/

3、二进制日志文件名前缀mysql-bin

4、文件名以"前缀".000001~N

log-bin=/data/mysql/mysql-bin

二进制日志的“分开关”:

只有总闸开启才有意义,默认是开启状态。

我们在有些时候会临时关闭掉。

只影响当前会话。

sql_log_bin=1/0

1.5 二进制日志的格式**

statement,语句模式:

记录信息简洁,记录的是SQL语句本身。但是在语句中出现函数操作的话,有可能记录的数据不准确。

5.6中默认模式,但生产环境中慎用,建议改成row。

row,行模式

表中行数据的变化过程。

记录数据详细,对IO性能要求比较高

记录数据在任何情况下都是准确的。

生产中一般是这种模式。

5.7以后默认的模式。

mixed,混合模式

经过判断,选择row+statement混合的一种记录模式。(一般不用)

1.6 开启二进制日志

mysql> show variables like ‘%log_bin%’;

±--------------------------------±------+

| Variable_name | Value |

±--------------------------------±------+

| log_bin | OFF |

| log_bin_basename | |

| log_bin_index | |

| log_bin_trust_function_creators | OFF |

| log_bin_use_v1_row_events | OFF |

| sql_log_bin | ON |

±--------------------------------±------+

6 rows in set (0.00 sec)

修改配置文件开启二进制日志

[root@db02 tmp]# vim /etc/my.cnf

[mysqld]

log-bin=/application/mysql/data/mysql-bin

命令行修改的方法

mysql> SET GLOBAL binlog_format = ‘STATEMENT’

mysql> SET GLOBAL binlog_format = ‘ROW’;

mysql> SET GLOBAL binlog_format = ‘MIXED’;

查看文件二进制日志的类型

[root@db02 data]# file mysql-bin.*

mysql-bin.000001: MySQL replication log

mysql-bin.index: ASCII text

查看MySQL的配置:

mysql> show variables like ‘%log_bin%’;

±--------------------------------±----------------------------------------+

| Variable_name | Value |

±--------------------------------±----------------------------------------+

| log_bin | ON |

| log_bin_basename | /application/mysql/data/mysql-bin |

| log_bin_index | /application/mysql/data/mysql-bin.index |

| log_bin_trust_function_creators | OFF |

| log_bin_use_v1_row_events | OFF |

| sql_log_bin | ON |

±--------------------------------±----------------------------------------+

6 rows in set (0.00 sec)

1.7 定义记录方式

查看现在的格式

mysql> show variables like ‘%format%’;

±-------------------------±------------------+

| Variable_name | Value |

±-------------------------±------------------+

| binlog_format | STATEMENT |

| date_format | %Y-%m-%d |

| datetime_format | %Y-%m-%d %H:%i:%s |

| default_week_format | 0 |

| innodb_file_format | Antelope |

| innodb_file_format_check | ON |

| innodb_file_format_max | Antelope |

| time_format | %H:%i:%s |

±-------------------------±------------------+

8 rows in set (0.00 sec)

修改格式

[root@db02 data]# vim /etc/my.cnf

[mysqld]

binlog_format=row

改完之后查看

mysql> show variables like ‘%format%’;

±-------------------------±------------------+

| Variable_name | Value |

±-------------------------±------------------+

| binlog_format | ROW |

| date_format | %Y-%m-%d |

| datetime_format | %Y-%m-%d %H:%i:%s |

| default_week_format | 0 |

| innodb_file_format | Antelope |

| innodb_file_format_check | ON |

| innodb_file_format_max | Antelope |

| time_format | %H:%i:%s |

±-------------------------±------------------+

8 rows in set (0.00 sec)

1.8 二进制日志的操作

1.8.1 查看

操作系统层面查看

[root@db02 data]# ll mysql-bin.*

-rw-rw---- 1 mysql mysql 143 Dec 20 20:17 mysql-bin.000001

-rw-rw---- 1 mysql mysql 120 Dec 20 20:17 mysql-bin.000002

-rw-rw---- 1 mysql mysql 82 Dec 20 20:17 mysql-bin.index

刷新日志

mysql> flush logs;

刷新完成后的日志目录

[root@db02 data]# ll mysql-bin.*

-rw-rw---- 1 mysql mysql 143 Dec 20 20:17 mysql-bin.000001

-rw-rw---- 1 mysql mysql 167 Dec 20 20:24 mysql-bin.000002

-rw-rw---- 1 mysql mysql 120 Dec 20 20:24 mysql-bin.000003

-rw-rw---- 1 mysql mysql 123 Dec 20 20:24 mysql-bin.index

[root@db02 data]#

查看当前使用的二进制日志文件

mysql> show master status;

±-----------------±---------±-------------±-----------------±------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

±-----------------±---------±-------------±-----------------±------------------+

| mysql-bin.000003 | 120 | | | |

±-----------------±---------±-------------±-----------------±------------------+

1 row in set (0.00 sec)

查看所有的二进制日志文件

mysql> show binary logs;

±-----------------±----------+

| Log_name | File_size |

±-----------------±----------+

| mysql-bin.000001 | 143 |

| mysql-bin.000002 | 167 |

| mysql-bin.000003 | 120 |

±-----------------±----------+

3 rows in set (0.00 sec)

1.8.2 查看二进制日志内容

名词说明:

1、events 事件

​    二进制日志如何定义:命令的最小发生单元

2、position

每个事件在整个二进制文件中想对应的位置号就是position号

mysql> show master status;

±-----------------±---------±-------------±-----------------±------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

±-----------------±---------±-------------±-----------------±------------------+

| mysql-bin.000003 | 120 | | | |

±-----------------±---------±-------------±-----------------±------------------+

1 row in set (0.00 sec)

[root@db02 data]# mysqlbinlog mysql-bin.000003 >/tmp/aa.ttt

导出所有的信息

[root@db02 data]# mysqlbinlog mysql-bin.000003 >/tmp/aa.ttt

binlog****的查看方式:

1、查看binlog原始信息

mysqbin mysql-bin.000002

2、在row模式下,翻译成语句

mysqlbinlog --base64-output=‘decode-rows’ -v mysql-bin.000002

3、查看binlog事件

show binary logs; 所有在使用的binlog信息

show binlog events in ‘日志文件’

4**、如何截取binlog内容,按需求恢复(常规思路)**

(1)、show binary logs; show master status;

(2)、show binlog events in ” 从后往前看,找到误操作的事务,判断事务开始position和结束position

(3)、把误操作的剔除掉,留下正常操作到2个sql文件中

(4)、先测试库恢复,把误操作的数据导出,然后生产恢复。

使用上述方法遇到的问题:

恢复事件较长

对生产数据有一定的影响,有可能会出现冗余数据

较好的解决方案。

1、flashback闪回功能

2、通过备份,延时从库

1.8.3 mysqlbinlog****截取二进制日志的方法

mysqlbinlog常见的选项有以下几个:

参数 参数说明
–start-datetime 从二进制日志中读取指定等于时间戳或者晚于本地计算机的时间
–stop-datetime 从二进制日志中读取指定小于时间戳或者等于本地计算机的时间取值和上述一样
–start-position 从二进制日志中读取指定position 事件位置作为开始。
–stop-position 从二进制日志中读取指定position 事件位置作为事件截至

二进制日志文件示例: mysqlbinlog —start-position=120 –stop-position=结束号

1.8.4 删除二进制日志

默认情况下,不会删除旧的日志文件。

根据存在时间删除日志:

SET GLOBAL expire_logs_days = 7;

PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day;

根据文件名删除日志:

PURGE BINARY LOGS TO ‘mysql-bin.000010’;

重置二进制日志计数,从1开始计数,删除原有的二进制日志。

reset master

1.9 mysql****的慢查询日志(slow log

1.9.1 这是什么呢?

slow-log 记录所有条件内的慢的sql语句

优化的一种工具日志。能够帮我们定位问题。

1.9.2 慢查询日志

是将mysql服务器中影响数据库性能的相关SQL语句记录到日志文件

通过对这些特殊的SQL语句分析,改进以达到提高数据库性能的目的。慢日志设置

long_query_time : 设定慢查询的阀值,超出次设定值的SQL即被记录到慢查询日志,缺省值为10s

slow_query_log : 指定是否开启慢查询日志

slow_query_log_file : 指定慢日志文件存放位置,可以为空,系统会给一个缺省的文件host_name-slow.log

min_examined_row_limit:查询检查返回少于该参数指定行的SQL不被记录到慢查询日志

log_queries_not_using_indexes: 不使用索引的慢查询日志是否记录到索引

慢查询日志配置

[root@db02 htdocs]# vim /etc/my.cnf

slow_query_log=ON

slow_query_log_file=/tmp/slow.log

long_query_time=0.5 # 控制慢日志记录的阈值

log_queries_not_using_indexes

​ 配置完成后重启服务…

查看慢查询日志是否开启,及其位置。

mysql> show variables like ‘%slow%’

​ -> ;

±--------------------------±--------------+

| Variable_name | Value |

±--------------------------±--------------+

| log_slow_admin_statements | OFF |

| log_slow_slave_statements | OFF |

| slow_launch_time | 2 |

| slow_query_log | ON |

| slow_query_log_file | /tmp/slow.log |

±--------------------------±--------------+

5 rows in set (0.00 sec)

1.9.3 mysqldumpslow****命令

/path/mysqldumpslow -s c -t 10 /database/mysql/slow-log

这会输出记录次数最多的10条SQL语句,其中:

参数 说明
-s 是表示按照何种方式排序,c、t、l、r分别是按照记录次数、时间、查询 时间、返回的记录数来排序,ac、at、al、ar,表示相应的倒叙;
-t 是top n的意思,即为返回前面多少条的数据;
-g 后边可以写一个正则匹配模式,大小写不敏感的;
例子: /path/mysqldumpslow -s r -t 10 /database/mysql/slow-log 得到返回记录集最多的10个查询。 /path/mysqldumpslow -s t -t 10 -g “left join”/database/mysql/slow-log 得到按照时间排序的前10条里面含有左连接的查询语句。

1.9.4 怎么保证binlogredolog已提交事务的一致性

在没有开启binlog的时候,在执行commit,认为redo日志持久化到磁盘文件中,commit命令就成功。

写binlog参数:

mysql> show variables like ‘%sync_binlog%’;

±--------------±------+

| Variable_name | Value |

±--------------±------+

| sync_binlog | 0 | #控制binlog commit 阶段

±--------------±------+

1 row in set (0.00 sec)

sync_binlog 确保是否每个提交的事务都写到binlog中。

1.9.5 mysql****中的双一标准:

innodb_flush_log_at_trx_commit和sync_binlog 两个参数是控制MySQL 磁盘写入策略以及数据安全性的关键参数。

参数意义说明:

innodb_flush_log_at_trx_commit=1

如果innodb_flush_log_at_trx_commit设置为0,log buffer将每秒一次地写入log file中,并且log file的flush(刷到磁盘)操作同时进行.该模式下,在事务提交的时候,不会主动触发写入磁盘的操作。

如果innodb_flush_log_at_trx_commit设置为1,每次事务提交时MySQL都会把log buffer的数据写入log file,并且flush(刷到磁盘)中去.

如果innodb_flush_log_at_trx_commit设置为2,每次事务提交时MySQL都会把log buffer的数据写入log file.但是flush(刷到磁盘)操作并不会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作。

注意:

由于进程调度策略问题,这个“每秒执行一次 flush(刷到磁盘)操作”并不是保证100%的“每秒”。

参数意义说明:

sync_binlog=1

sync_binlog 的默认值是0,像操作系统刷其他文件的机制一样,MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。

当sync_binlog =N (N>0) ,MySQL 在每写 N次 二进制日志binary log时,会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。

***

如果启用了autocommit,那么每一个语句statement就会有一次写操作;否则每个事务对应一个写操作。

安全方面说明

当innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的,在mysqld 服务崩溃或者服务器主机crash的情况下,binary log 只有可能丢失最多一个语句或者一个事务。但是鱼与熊掌不可兼得,双11 会导致频繁的io操作,因此该模式也是最慢的一种方式。

当innodb_flush_log_at_trx_commit设置为0,mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。

当innodb_flush_log_at_trx_commit设置为2,只有在操作系统崩溃或者系统掉电的情况下,上一秒钟所有事务数据才可能丢失。

双1适合数据安全性要求非常高,而且磁盘IO写能力足够支持业务,比如订单,交易,充值,支付消费系统。双1模式下,当磁盘IO无法满足业务需求时 比如11.11 活动的压力。推荐的做法是 innodb_flush_log_at_trx_commit=2 ,sync_binlog=N (N为500 或1000) 且使用带蓄电池后备电源的缓存cache,防止系统断电异常。

系统性能和数据安全是业务系统高可用稳定的必要因素。我们对系统的优化需要寻找一个平衡点,合适的才是最好的,根据不同的业务场景需求,可以将两个参数做组合调整,以便是db系统的性能达到最优化。

你可能感兴趣的:(大数据)