日志种类 |
作用 |
错误日志 |
记录 MySQL 服务器启动、关闭及运行错误等信息 |
事务日志 |
1、redo log重做日志 2、undo log回滚日志 |
查询日志 |
记录所有的sql |
慢查询日志 |
记录执行时间超过指定时间的操作,如果是全表查询,即便没有超时也会被记录下来 |
二进制日志 |
又称binlog日志,以二进制文件的方式记录数据库中除 SELECT 以外的操作。即只记录写操作不记录读操作 |
中继日志 |
备库将主库的二进制日志复制到自己的中继日志中,从而在本地进行重放 |
通用日志 |
审计哪个账号、在哪个时段、做了哪些事件 |
错误日志使用log_error以及log_warnings等参数进行定义
首次启动会提示错误日志位置,后期查询错误日志存放路径的命令如下
| [root@db01 ~] |
| |
| 或者 |
| [root@db01t ~] |
| mysql> show variables like '%log_error%'; |
log_error变量用于设置错误日志的存放位置(默认就是启用的)
| [root@localhost ~] |
| [mysqld] |
| |
| log_error=/var/log/mysql.errlog |
| |
| |
| |
| [root@localhost ~] |
| [root@localhost ~] |
| [root@localhost ~] |
| [root@localhost ~] |
log_warnings用于标识警告信息是否一并记录到错误日志中
在MySQL 5.6中用log_warnings参数
| log_warnings的值为0,表示不记录警告信息。 |
| log_warnings的值为1,表示警告信息一并记录到错误日志中。 |
| log_warnings的值大于1,表示"失败的连接"的信息和创建新连接时"拒绝访问"类的错误信息也会被记录到错误日志中。 |
| |
| mysql5.5中log_warnings参数的默认值为1 |
| mysql5.7中log_warnings参数的默认值为2 |
| mysql> show variables like "%log_warnings%"; |
mysql5.7新增的log_error_verbosity参数
redo与undo详见《day10 MySQL事务中的redo与undo》
| 1.默认是关闭的 |
| 一般不会开启,因为哪怕你开启事务一顿操作,最后不提交也会记录,生产上程序跑sql很多,会非常非常占地方,从来都不启动,要看操作去binlog |
| |
| 2.开启 |
| [root@db01 ~]# vim /etc/my.cnf |
| general_log=on |
| general_log_file=/var/log/select.log |
| #可以使用set global general_log=on;设置 |
| |
| [root@localhost ~]# touch /var/log/select.log |
| [root@localhost ~]# chmod 640 /var/log/select.log |
| [root@localhost ~]# chown mysql.mysql /var/log/select.log |
| [root@localhost ~]# systemctl restart mysqld |
| 3.查看一般查询日志 |
| [root@db01 ~]# mysqladmin -uroot -pEgon@123 variables|grep general_log |
| |
| 或者 |
| [root@db01 ~]# mysql -uroot -pEgon@123 |
| mysql> show variables like '%gen%'; |
| 1)将mysql服务器中影响数据库性能的相关SQL语句(不论是什么语句,增删改查)记录到日志文件 |
| 2)通过对这些特殊的SQL语句分析并改进,提高数据库性能 |
| |
| |
| [root@db01 ~] |
| [mysqld] |
| |
| slow_query_log = 1 |
| |
| slow_query_log_file=/var/log/slow.log |
| |
| long_query_time=0.05 |
| |
| log_queries_not_using_indexes=ON |
| |
| |
| |
| 执行下述命令 |
| touch /var/log/slow.log |
| chmod 640 /var/log/slow.log |
| chown mysql.mysql /var/log/slow.log |
| systemctl restart mysqld |
测试方式一
| 测试:BENCHMARK(count,expr) |
| SELECT BENCHMARK(50000000,2*3); |
| |
| |
| show processlist; |
| kill 3; |
测试方式二
| insert city_new select * from city; |
| insert city_new select * from city_new; |
| insert city_new select * from city_new; |
| insert city_new select * from city_new; |
查看方式一
| 查看慢日志可以使用 |
| cat /service/mysql/data/slow.log |
| 看起来太费劲,我们使用方式二 |
查看方式二
| mysqldumpslow -s r -t 10 /var/log/slow.log |
| |
| 得到按照时间排序的前10条里面含有左连接的查询语句 |
| 参数说明: |
| -s:指定排序方式 |
| c、t、l、r分别是按照记录次数、时间、查询时间、 |
| 返回的记录数来排序,ac、at、al、ar,表示相应的倒叙 |
| |
| -t:是top n的意思,即为返回前面多少条的数据; |
| |
| -g:后边可以写一个正则匹配模式,大小写不敏感的; |
查看方式三
| yum provides pt-query-digest |
二进制日志即binlog日志,记录了mysql数据库所有的dml,ddl语句事件(不包含select)。记录增删改,也可以记录SQL语句及行记录变化,还可以记录这些操作事件;总之会记录所有修改操作的SQL语句。
不要混淆以下三种日志:
(1)general log:记录数据库里的所有SQL操作记录
(2)redo log:只记录innodb存储引擎的修改日志
(3)binlog:只记录server层面内部的修改情况。–select /show 不记录
| (1)数据恢复:可以基于时间点恢复,以及根据其进行增量与差异备份 |
| (2)mysql主从复制,通过binlog实现数据复制 |
(1)语句模式:binlog_format=statement(Mysql5.7.6之前的默认级别)
| |
| 记录对数据库做出修改的sql语句,不记录该sql的上下文信息 |
| |
| 例如 |
| 1、开启binlog日志后,我们在某个库下自定义函数,若想定义成功需要先设置配置项 |
| set global log_bin_trust_function_creators=TRUE; |
| |
| 2、然后自定义函数 |
| delimiter // |
| create function f1( |
| i1 int, |
| i2 int) |
| returns int |
| BEGIN |
| declare num int; |
| set num = i1 + i2; |
| return(num); |
| END // |
| delimiter ; |
| |
| 3、最后执行一条插入语句 |
| insert into t1(name) values(concat("egon",f1(1,2))); |
| |
| 如果使用statement模式,那么这条insert语句将会被记录到二进制日志中,而sql语句中依赖的f1的定义是不会记录下来的,f1只存在于当前库。 |
| |
| |
| 不需要记录细到每一行数据的更改变化,因此,binlog日志量小,IO压力小,性能较高 |
| |
| 例如: |
| 一条语句修改了100万行,该模式下只需要记录下该条语句即可 |
| |
| |
| 日志中记录的sql语句可能有上下文依赖,此时脱离了当前数据库环就无法运行了,因此该模式下容易出现主从不一致的问题。 |
| |
| 例如: |
| 主库记录的某条sql语句引用了主库中的函数、触发器、存储过程等特殊功能 |
| 在从库上接收了该sql之后,可能就无法正确运行,从而主从库数据不一致的问题。 |
| |
| ps:row模式是基于每一行来记录变化的,所以不会出现类似的问题。 |
| |
| |
| sql语句对mysql内置功能依赖比较少:不使用存储过程/触发器/函数,可以使用该模式,否则还是推荐行级模式 |
(2)行级模式:binlog_format=row,(mysql5.7.6之后+8.0的默认级别)
| |
| 记录每一行数据修改的细节,即哪一条记录被修改了,修改成什么样了 |
| |
| 例如:执行语句(f1参照上例,此处略) |
| insert into t1(name) values(concat("egon",f1(1,2))); |
| |
| 如果使用row模式,那么日志中会记录插入了一条新记录,记录中的name字段值为'egon3' |
| |
| |
| 相当于把上下文依赖都记录了下来,可以更方便查看每一条数据修改的细节,并且不会出现某些特定情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题,即该模式下主从复制强一致,数据最安全。 |
| |
| |
| 日志量大 |
| |
| 例如 |
| 一条语句修改了100万行,语句模式下只需要记录一条语句即可 |
| 而行级模式却修改记录下100万行的修改记录,binlog日志的量可能会大得惊人。 |
| |
| |
| sql语句对mysql内置功能依赖比较多,希望数据最安全,复制强一致的场景推荐行级模式 |
(3)混合模式:binlog_format=mixed,一般不用
| |
| 结合 row level 与statement level的优点 |
| 混合(mixed-based)模式默认采用语句模式记录日志,在一些特定的情况下会将记录模式切换为行级模式记录,这些特殊情况包含但不限于以下情况。 |
| •当函数中包含UUID()时。 |
| •当表中有自增列(AUTO_INCREMENT)被更新时。 |
| •当执行触发器(trigger)或者存储过程(stored function)等特殊功能时。 |
| •当FOUND_ROWS()、ROW_COUNT()、USER()、CURRENT_USER()、CURRENT_USER等执行时。 |
| |
| |
| 看上去这种方式似乎比较美好,但是在生产环境中,为了保险起见,一般会使用row模式。 |
二进制日志文件,顾名思义,它是二进制的,所以我们不能直接使用cat命令进行查看,而是需要通过一些别的命令查看其内容,而且,二进制日志文件,有”事件”和”位置”的概念,什么是事件呢?
通俗的讲,我们可以把binlog中的每一条记录当做一个”事件”,因为binlog记录了所有对数据库进行的修改,所以,我们可以认为,数据库的修改被记录到二进制日志中,这些记录每一条都可以理解为一个”事件”。
由于二进制日志文件是二进制的,所以,我们可以把整个二进制文件想象成一个字节序列。假设,二进制日志文件刚开始是空的,从第1个字节开始记录,假设记录第一个”事件”(第一条记录),需要15个字节,那么第一个事件的开始”位置”就是1,结束”位置”就是15,由于前15个字节已经被第一个事件占用,那么当我们想要通过二进制日志记录第二个事件时,则需要从第15个字节向后开始记录,假设记录第二个”事件”需要20个字节,那么第二个事件在binlog中的起始”位置”就是15,结束”位置”就是35,以此类推。
| 服务ID,主从库必须不一样,建议数字为:ip+端口,5.7.3以后版本,必须指定 |
| 此变量用于控制是否开启二进制日志,而且这是一个只读变量,默认值为OFF |
| |
| 当我们启动数据库以后,在当前数据库连接中查看此变量的值,此变量值可能为OFF,表示不记录二进制日志,如果想要记录二进制日志,只需将此值设置为二进制日志的文件名即可,但是需要注意的是,我们无法在当前会话中使用set命令设置log_bin的值,因为它是一个只读变量,我们只能通过修改my.cnf的方式,设置log_bin的值,假设,我们编辑my.cnf文件,设置log_bin的值为mybinlog,那么,在mysql的数据目录中,将会自动生成一个以mybinlog为文件名前缀的二进制日志文件,如果想要再次禁用binlog,只需要将log_bin这一行配置从my.cnf文件中注释即可,或者将其删除,重启mysql服务后,再次查看log_bin的值,其值为OFF,注意,不要直接在my.cnf文件中将log_bin的值设置为ON或者OFF,如果这样做,你将会看到以ON或者OFF为文件名前缀的二进制日志文件。换句话说,如果my.cnf配置文件中没有log_bin的配置,则表示未开启二进制日志,如果my.cnf中存在log_bin的配置,那么则表示开启了二进制日志,同时二进制日志文件的名称将会以log_bin对应的值为文件名前缀,同时,二进制日志文件的后缀名会进行自动编号,每次日志滚动后,后缀名编号自动加1。 |
| |
| 示例: |
| log-bin=/var/lib/mysql/mybinlog |
| |
| 不设置的话,会根据log_bin值名称自动生成mybinlog.index |
| log_bin_index=var/lib/mysql/mybinlog.index |
| 默认为ON |
| 此变量用于标识当前会话中的操作是否会被记录于二进制日志,此变量值设置为ON,则表示在当前数据库连接中,对数据库进行修改的语句将会被记录到binlog中,此变量值设置为OFF,则表示在当前数据库连接中,对数据库进行的修改的语句将不会被记录到binlog中,在主从复制结构中,这些语句由于没有被binlog记录,所以也不会同步到从节点中。换句话说,即使在my.cnf配置文件中设置了log_bin的值,当前会话中,如果sql_log_bin的值设置为OFF,当前会话的操作也不会记录在二进制日志中。而且需要注意的是,sql_log_bin是一个会话界别的变量,只能在当前会话中使用set sql_log_bin命令进行设置,不能使用set global sql_log_bin命令进行设置,因为它是会话级别的变量,而且,sql_log_bin也不能配置在my.cnf文件中,否则可能会无法启动mysql。 |
| 此变量值得含义上文已经解释过,此变量的值决定了二进制日志的记录方式,此变量的值可以设置为statement、row、mixed,分别表示以语句的形式记录二进制日志,以数据修改的形式记录二进制日志,以混合的方式记录二进制日志,安全保险起见,推荐使用row的方式记录。 |
| 设置单个二进制日志文件的最大大小,以字节为单位,超过此值大小,则二进制日志文件会自动滚动,比如设置为500M为524288000。 |
| 在存储引擎章节中我们提过: |
| innodb_flush_log_at_trx_commit控制redo日志的刷盘策略,建议值为1 |
| sync_binlog控制binlog日志的刷盘策略,建议值为1 |
| |
| 当我们把innodb_flush_log_at_trx_commit设置为1的时候,表示事务提交时,事务日志立马从内存刷写到磁盘中的事务日志文件中,而sync_binlog对于二进制日志的作用,就像innodb_flush_log_at_trx_commit对于事务日志的作用,由于二进制日志一开始存在于内存(binlog_cache)中,如果将sync_binlog设置为1,则表示每1次事务提交之后,都会立即将内存中的二进制日志立即同步到磁盘中的二进制日志文件中,如果将sync_binlog设置为0,则表示当事务提交之后,mysql不会立即将内存中的binlog刷写到磁盘中的binlog日志文件中,而是由文件系统决定什么时候刷写,这可能取决于文件系统的缓存机制,当此值设置为0时,一旦操作系统宕机,那么将丢失未从内存中同步到磁盘中的binlog,所以,当此值设置为0时,安全性最差,但是性能最高,当此值设置为1时,安全性最高,性能最差,除了将此值设置为0或1,还能设置为N,假设将此值设置为3,则表示每3次事务提交后,将binlog从内存刷写到磁盘一次,值设置的越大,有可能丢失的日志数据将会越多,当然,性能会越好,在追求安全的情况下,推荐设置为1,但是听说,此值设置为0和设置为1时在性能上的差距还是比较明显的,如果设置为0或N,最好为操作系统准备带有备用电源的缓存。 |
| |
| binlog_rows_query_log_events=on |
| |
| |
| expire_logs_days=10 |
| |
| |
| binlog_row_image=full |
| show variables like '%log_bin%'; |
| show variables like '%binlog%'; |
| show variables like '%binlog_format%'; |
| show variables like '%server%'; |
| show variables like 'expire_logs_days'; -- 过期日志天数 |
| |
| |
| [root@db01 ~] |
| 1.默认是关闭的 |
| |
| 2.配置开启binlog |
| vim /etc/my.cnf |
| [mysqld] |
| server_id=1 |
| log-bin=/var/lib/mysql/mybinlog |
| binlog_format='row' |
| binlog_rows_query_log_events=on |
| max_binlog_size=100M |
查看日志日志名、状态、事件