MySQL其他数据库日志

目录

1.MySQL支持的日志

2.慢查询日志(slow query log)

2.1 慢查询日志相关参数

2.2 开启慢查询日志

2.3 数据记录

3.通用查询日志(general query log)

3.1 查看当前开启状态

3.2 启动方式

3.3 数据记录

3.4 删除/刷新日志

4.错误日志(error log)

4.1 启动日志

4.2 查看日志 

4.3 删除/刷新日志        

5.二进制日志(bin log)

5.1 查看默认情况

5.2 日志参数设置

5.3 查看日志

5.4 使用日志恢复数据

5.5 删除二进制日志

5.6 其他场景

5.7 写入机制

5.8 bin log与redo log对比

5.9 两阶段提交

6.中继日志(relay log)

6.1 介绍

6.2 查看中继日志


        之前写数据库事务的时候,写过两种日志:重做日志(redo log)、回滚日志(undo log)。对于线上数据库系统,如果发生突然宕机,那么定位到宕机的原因就很关键。我们可以查看数据库的错误日志,因为日志中记录了数据库运行中的诊断信息,包括了错误、警告和注释等信息。

1.MySQL支持的日志

        MySQL有不同类型的日志文件,用来存储不同类型的日志,分为二进制日志、错误日志、通用查询日志和慢查询日志,这是常用的4种日志。MySQL8.0又新增了两种支持的日志:中继日志和数据定义语句日志。

        慢查询日志:记录所有执行时间超过long_query_time的所有查询,方便我们对查询进行优化。

        通用查询日志:记录所有连接起始时间和终止时间,以及连接发送给数据库服务器的所有指令。

        错误日志:记录MySQL服务启动、运行或停止服务时出现的问题,方便我们了解服务器状态。

        二进制日志:记录所有更改数据的语句,可以用于主从服务器之间的数据同步,以及服务器遇到故障时数据的无损恢复。

        中继日志:用于主从服务器架构中,从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容,来同步主服务器上的操作。

        除二进制文件外,其他日志都是文本文件。默认情况下,所有日志创建于MySQL数据目录中。

2.慢查询日志(slow query log)

        MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中。long_query_time的默认值为10,意思是运行10S以上的语句。默认情况下,Mysql数据库并不启动慢查询日志,需要我们手动来设置这个参数,当然,如果不是调优需要的话,一般不建议启动该参数,因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件,也支持将日志记录写入数据库表。

2.1 慢查询日志相关参数

        slow_query_log:是否开启慢查询日志,1表示开启,0表示关闭。

        slow-query-log-file:慢查询日志存储路径。可以不设置该参数,系统则会默认给一个缺省的文件host_name-slow.log

        long_query_time:慢查询阈值,当查询时间多于设定的阈值时,记录日志。

        log_queries_not_using_indexes:未使用索引的查询也被记录到慢查询日志中(可选项)。

        log_output:日志存储方式。log_output = 'FILE'表示将日志存入文件,默认值是'FILE'。log_output = 'TABLE'表示将日志存入数据库,这样日志信息就会被写入到mysql.slow_log表中。MySQL数据库支持同时两种日志存储方式,配置的时候以逗号隔开即可,如:log_output = 'FILE,TABLE'。日志记录到系统的专用日志表中,要比记录到文件耗费更多的系统资源,因此对于需要启用慢查询日志,又需要能够获得更高的系统性能,那么建议优先记录到文件。

2.2 开启慢查询日志

 show variables  like '%slow_query_log%';

永久开启

        修改my.cnf文件,新增下列参数配置

[mysqld]
slow_query_log=1
slow_query_log_file=/var/lib/mysql/atguigu-slow.log
long_query_time=3
log_output=FILE

临时开启(重启服务器后失效)

set global slow_query_log = 1;

2.3 数据记录

        开启后在mysql数据目录下会生成一个xxx-slow.log的文件。

        新开一个session执行 select sleep(4);操作,然后打开慢查询日志文件查看。

3.通用查询日志(general query log)

        通用查询日志用来记录用户的所有操作,包括启动和关闭MySQL、所有用户连接开始时间和截止时间、发给MySQL数据库服务器的所有SQL指令等。当我们的数据发生异常时,查看通用查询日志,可以帮助我们还原当时具体场景,定位问题。        

3.1 查看当前开启状态

show variables like '%general%';

3.2 启动方式

方式1:永久性启动

        修改my.cnf配置文件来设置。在【mysqld】组下加入log选项,并重启MySQL服务。

[mysqld]
general_log=ON
general_log_file=[path[filename]]

        如果不指定目录和文件名,通用查询日志将默认存储在MySQL数据目录中的hostname.log中,hostname表示主机名。        

方式2:临时性启动(重启服务器后失效)

SET GLOBAL general_log = ON

3.3 数据记录

        可以看到在 general_log_file路径下生成了一个名为iz2ze6890p10n5yp0jerfrz.log的日志文件。

        新开一个session执行增删改查操作,然后打开通用查询日志文件查看。

        可以看到增删改查操作都被记录到了通用查询日志里。

3.4 删除/刷新日志

         MySQL通用查询日志是以文本文件的形式存储在文件系统中的,可以直接删除。

rm -f  iz2ze6890p10n5yp0jerfrz.log.log

        在运行状态下删除错误日志后,MySQL并不会自动创建日志文件。重建日志指令:

mysqladmin -uroot -proot flush-logs

4.错误日志(error log)

        错误日志记录了MySQL服务器启动、停止运行的时间,以及系统启动、运行和停止过程中的诊断信息,包括错误警告提示等。通过错误日志可以查看系统的运行状态,便于及时发现故障、修复故障。

4.1 启动日志

        在MySQ中,错误日志功能是默认开启且无法被禁止的。默认情况下,错误日志在MySQL数据文件夹下,名称默认为mysqld.log。在配置文件中可以对文件生成路径进行配置:

4.2 查看日志 

show variables like 'log_err%';

4.3 删除/刷新日志        

        MySQL错误日志是以文本文件的形式存储在文件系统中的,可以直接删除。

rm -f mysqld.log

        在运行状态下删除错误日志后,MySQL并不会自动创建日志文件。重建日志指令:

mysqladmin -uroot -proot flush-logs

        如果报错则执行:

install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log

5.二进制日志(bin log)

5.1 查看默认情况

        binlog即binary log,二进制日志文件,也叫做变更日志(update log)。它记录了数据库所有执行的DDL和DML等数据库更新事件的语句,但是不包含没有修改任何数据的语句(如select、show等)。

        它以事件形式记录并保存在二进制文件中。通过这些信息,我们可以再现数据更新操作的全过程。

5.2 日志参数设置

show variables like '%log_bin%';

        log_bin:是否开启bin log。

        log_bin_basename:bin log存放路径。

        log_bin_index:bin log索引文件存放路径。

        log_bin_trust_function_creators:是否信任bin log中的函数。

        log_bin_use_v1_row_events:bin log版本信息,从5.6默认使用v2,所以该参数为OFF

        sql_log_bin:变更型sql文件是否记录到bin log中。

        启动方式:修改my.cnf配置文件来设置,并重启MySQL服务。

5.3 查看日志

        方式一:mysqlbinlog 

mysqlbinlog - v "/usr/local/mysql/data/mysql-bin.000001"   

        -v:按照事件的方式展示

        方式二:show binlog events

show binlog events [in 'log_name'] [from pos][limit [offset] row_count]

        in 'log_name':指定要查询的binlog文件名(不指定默认第一个文件)

        from pos:指定从哪个pos起始点开始查

        limit [offset]:偏移量(不指定就是0)

        row_count:查询总条数(不指定就是所有行)

5.4 使用日志恢复数据

        如果MySQL服务器启用了二进制日志,在数据库出现意外丢失数据时,可以使用MySQLbinlog工具从指定的时间点开始,直到现在或另一个指定时间点的日志中恢复数据。

        mysqlbinlog恢复数据的语法如下:

mysqlbinlog [option] filename|mysql -uuser -ppass

        filename:日志文件名

        option:可选项,比较重要的两对option参数是--start-date、--stop-date和--start-position、--stop-position

        --start-date和--stop-date:可以指定恢复数据库的起始时间和结束时间点

        --start-position、--stop-position:可以指定恢复数据哭的开始位置和结束位置

        注:使用mysqlbinlog命令进行恢复操作时,必须是编号小的文件先恢复,例如mysql-bin.000001必须在mysql-bin.000002之前恢复。

5.5 删除二进制日志

        MySQL的二进制文件可以配置自动删除,同时MySQL也提供了安全手动删除二进制文件的方法。PURGE MASTER LOGS只删除指定部分的二进制日志文件,RESET MASTER删除所有的二进制日志文件。具体如下:

PURGE MASTER LOGS:删除指定日志文件

 语法如下:

PURGE {MASTER|BINARY} LOGS TO '指定日志文件名'
PURGE {MASTER|BINARY} LOGS BEFORE'指定日期'

        删除指定文件名之前的日志文件或删除指定日期之前的日志文件

RESET MASTER:删除所有二进制日志文件

        RESET MASTER指令会清空所有的binlog日志。MySQL会重新创建二进制文件,新的日志文件扩展名将重新从000001开始编号。

5.6 应用场景

数据恢复

        如果MySQL服务器意外停止,可以通过二进制日志文件来查看用户执行了哪些操作,对数据库服务器文件做了哪些修改,然后根据二进制日志文件中的记录来恢复数据库数据。

数据复制

        master主机把它的二进制日志传递给slaves来达到主从数据一致。

5.7 写入机制

        在事务执行过程中,MySQL先把日志写到binlog cache中,事务提交的时候,再把binlog cache写到binlog文件中。因为一个事务的binlog不能被拆开,无论这个事务多大,也要保证一次性写入,所以系统会给每个线程分配一个块内存作为binlog cache。

        我们可以通过binlog_cache_size参数控制单个线程binlog cache大小,如果存储内容超过了这个参数的容量,就要把binlog cache中的数据刷到磁盘上。binlog日志刷盘流程如下:

        上图的write,是指把日志写入到文件系统的page cache,并没有把数据持久化到磁盘,所以速度比较快
        上图的fsync,才是将数据持久化到磁盘的操作

        write和fsync的时机,可以由参数sync_binlog控制,默认是0。为0的时候,表示每次提交事务都只write,由系统自行判断什么时候执行fsync。虽然性能得到提升,但是机器宕机,page cache里面的binglog会丢失。

        为了安全起见,可以设置为1,表示每次提交事务都会执行fsync,就如同binlog日志刷盘流程一样。最后还有一种折中方式,可以设置为N(N>1),表示每次提交事务都write,但累积N个事务后才fsync。在出现IO瓶颈的场景里,将sync_binlog设置成一个比较大的值,可以提升性能。同样的,如果机器宕机,会丢失最近N个事务的binlog日志。         

5.8 bin log与redo log对比

        redo log是物理日志,记录内容是"在某个数据页上做了什么修改",属于InnoDB存储引擎层产生的。

        binlog是逻辑日志,记录内容是语句的原始逻辑,类似于"给 ID = 2这一行的C字段加1"。属于MySQL的 Server层。

        redo log和bin log都属于数据库持久化的保证,但侧重点不同。redo log侧重让InnoDB拥有崩溃恢复的能力。bin log保证了MySQL集群数据的一致性。

5.9 两阶段提交

        在执行更新语句过程中,会记录redo log和bin log两部分日志,以基本的事务为单位,redo log在事务执行过程中可以不断的写入,而bin log只有在提交事务时才写入,所以redo log与bin log的写入时机不一样。

        如果redo log与bin log两份日志之间的逻辑不一致,比如redo log记录正常但bin log记录失败,那么就会造成主从数据库间的数据不一致。

        为了保证两份日志的逻辑一致性MySQL采用了两阶段提交。下面是一个 update 语句的执行流程图,图中浅色框表示是在 InnoDB 内部执行的,深色框表示是在执行器中执行的。

                                                      图片借鉴于:MySql事务之两阶段提交与redo log、binlog - 简书 

        "两阶段提交"的逻辑也很简单,就是将redo log的写入拆成了两个步骤:prepare 和 commit。在commit阶段会判断bin log是否写入成功再去提交。简单来说,redo log和bin log都可以用于表示事务的提交状态,而两阶段提交就是让这两个状态保持逻辑上的一致。

6.中继日志(relay log)

6.1 介绍

        中继日志只在主从服务器架构的从服务器上存在。从服务器为了与主服务器保持数据一致,要从主服务器读取二进制日志的内容,并把读取到的信息写入本地的日志文件中,这个存储在从服务器本地的日志文件叫做中继日志

        搭建好从服务器后,中继日志默认保存在从服务器数据目录下。中继日志还有一个索引文件:从服务器名-relay-bin.index,用来定位当前正在使用的中继日志。

6.2 查看中继日志

        中继日志与二进制日志格式相同,可以用mysqlbinlog工具进行查看。

  • 1
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值