MySQL/MariaDB的日志

最新推荐文章于 2024-06-04 13:46:00 发布

weixin_34018202

最新推荐文章于 2024-06-04 13:46:00 发布

阅读量106

点赞数

文章标签：操作系统数据库

原文链接：http://blog.51cto.com/liujingyu/2157398

版权

在Mysql/MariaDB的日志大致分为下列几种：

查询日志

一般查询日志：

慢查询日志：

错误日志

二进制日志

中继日志

事务日志

简要介绍一下这几种日志，日志对我们分析MySQL服务有着很重要的帮助；

查询日志：

一般查询日志：默认关闭，因为会记录所有的查询语句；

MariaDB [(none)]> select @@general_log;
+---------------+
| @@general_log |
+---------------+
|             0 |
+---------------+

慢查询日志：默认关闭，建议开启，在SQL语句调优和MySQL服务器性能分析时具有一定的参考意义；

指的是查询时间超过服务器参数long_query_time所设定的时间的查询语句；但是查询获取锁的时间不计入查询时间考核内；

MariaDB [(none)]> show global variables like 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+

慢查询日志可以以两种形式存放，也受log_output服务器参数的控制；

1. 以文件的形式存放于文件系统中；

2. 以系统表的形式存放于mysql.slow_log表中；

慢查询日志的功能开关：

log_slow_queries { ON | OFF }

slow_query_log { ON | OFF }

慢查询日志的功能开关，如果两个开关都在，则修改一个的值，另一个值也随之改变；

MariaDB [(none)]> select @@log_slow_queries;
+--------------------+
| @@log_slow_queries |
+--------------------+
|                  0 |
+--------------------+
1 row in set (0.00 sec)

MariaDB [(none)]> select @@slow_query_log;
+------------------+
| @@slow_query_log |
+------------------+
|                0 |
+------------------+

log_slow_rate_limit = N 慢查询日志的记录频率；

log_slow_verbosity { ON | OFF } 是否详细记录慢查询日志的功能开关；

slow_query_log_file /PATH

只有log_output服务器参数的值为FILE时，此服务器参数才有效；其值为慢查询日志的存放路径及文件名称；默认路径为数据目录(datadir), 文件名为：HOSTNAME-slow.log；

log_queries_not_using_indexes { ON | OFF }

对于那些没有使用索引导致的慢查询是否记录于慢查询日志的功能开关；默认值为OFF；

测试慢查询：

MariaDB [(none)]> select sleep(10);
+-----------+
| sleep(10) |
+-----------+
|         0 |
+-----------+

mysql的客户端工具mysqldumpslow可以帮助分析慢查询日志；

常用选项：

-a：在归类是不使用N代替数字，不使用S代替字符串；

--debug, -d：输出调试信息，更方便日志分析；

-t N：仅显示慢查询日志中的前N条慢查询结果；

--verbose, -v：显示详细信息；

-g pattern：通过grep进行select语句的筛选；

[root@master ~]# mysqldumpslow -a -v

Reading mysql slow query log from /var/lib/mysql/master-slow.log
Count: 1  Time=10.00s (10s)  Lock=0.00s (0s)  Rows_sent=1.0 (1), Rows_examined=0.0 (0), root[root]@localhost
  select sleep(10)

错误日志：

可以记录信息的内容

1.mysqld|mysqld_safe程序启动或关闭的过程中输出的信息；

2.mysqld服务运行过程中产生的错误信息；

3.时间调度器在运行时产生的信息；

4.在主从架构的MySQL复制模型中，SLAVE服务器的复制线程启动时产生的信息；

5.可以通过log_warnings的服务器参数控制将"Warning"类的信息记录于此；

MariaDB [(none)]> select @@log_error;
+------------------------------+
| @@log_error                  |
+------------------------------+
| /var/log/mariadb/mariadb.log |
+------------------------------+

与错误日志先关的服务器变量参数；

log_error /var/log/mariadb/mariadb.log

开启错误日志记录，并定义记录错误日志的文件路径及文件名；

log_warnings 1

是否将mysqld运行过程中产生的"Warning"类的信息一并记录在错误日志文件中的功能开关；

二进制日志：

二进制日志包含了引起或可能引起数据变化的事件的信息：如：

insert，update，delete

update和delete语句在执行时根据指定的条件没有匹配的行；

create，alter，drop

但是诸如select或show这样的查询语句，绝对不会被记录在二进制日志中；

二进制日志中的"事件"，包含了引起数据变化或可能引起数据变化的SQL语句或SQL语句的执行结果，也有可能是二者的混合；

1.如果记录SQL语句，日志中记录的数据量比较小，可能产生潜在的结果不一致，比如与时间有关的函数的执行结果；

2.如果记录SQL语句的执行结果，能够精确的保存数据结果集，但是可能会导致数据量过于庞大；

到底该如何记录二进制日志内容，由一个服务器参数来决定的；

binlog_format STATEMENT

该变量的取值：

STATEMENT：以SQL语句方式记录二进制日志；

ROW：以SQL语句在执行之后发送改变的数据行的信息记录二进制日志；

MIXED：混合模式，STATEMENT和ROW两种模式都支持，但是在记录某个事件时，只能选择一种格式来记录，由MySQL自行决定到底使用何种格式；

MariaDB [(none)]> show global variables like 'binlog_format';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+

二进制日志的功能：数据重放；

1.主从复制

2.用于数据的增量备份；

MySQL或MariaDB默认并没有开启二进制日志的记录的功能，如果想要开启；

1.修改服务器参数：

SET @@GLOBAL.logbin={ ON | OFF | PATH }

2.修改配置文件：

在主配置文件/etc/my.cnf，添加一行

log_bin=/PATH/TO/binlog

注意：

1) MySQL或MariaDB 5.5+中，不支持ON或OFF的开关值，仅支持路径；

2) 二进制日志文件的路径，原则上讲，不应该与数据库存放在同一个存储设备之上；

可以通过mysql的交互模式查看二进制文件的列表，查看当前正在使用的日志文件；

MariaDB [(none)]> show master logs;
+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| binlog.000001 |      3478 |
| binlog.000002 |     33156 |
| binlog.000003 |      1568 |
| binlog.000004 |       264 |
| binlog.000005 |       264 |
| binlog.000006 |       245 |
+---------------+-----------+
MariaDB [(none)]> show master status;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000006 |      245 |              |                  |
+---------------+----------+--------------+------------------+

查看某指定的二进制文件中的时间内容：

MariaDB [(none)]> show binlog events  in 'binlog.000006'\G
*************************** 1. row ***************************
   Log_name: binlog.000006
        Pos: 4
 Event_type: Format_desc
  Server_id: 101
End_log_pos: 245
       Info: Server ver: 5.5.56-MariaDB, Binlog ver: 4

二进制日志的滚动：

自动滚动：由MySQL自行控制的日志滚动；

通过服务器参数来控制的单个二进制日志文件的大小上限；

MariaDB [(none)]> show global variables like 'max_binlog_size';
+-----------------+------------+
| Variable_name   | Value      |
+-----------------+------------+
| max_binlog_size | 1073741824 |
+-----------------+------------+

注意：因为二进制日志是在事务提交之后才会保存且每个事务都必须存放于一个二进制日志文件中，所以一些大事务的提交可能使得二进制日志文件的大小超过这个上限的值；

手动滚动：由用户控制的日志滚动；

1.重启MySQL服务；

2.在MySQL客户端的交互式模式中执行"FLUSH LOGS"语句；

其他的一些与二进制日志有关的重要参数信息；

sql_log_bin = { ON | OFF }

指定是否启用二进制日志功能；只有在log_bin参数的值为ON时有效；

sync_binlog = N

sync_binlog=0：异步更新；

MySQL不会选择同步缓存的信息到磁盘文件，缓存中的二进制日志何时刷写到磁盘由文件系统决定；该参数设定时MySQL的性能很好，但并不能很好的保证数据的一致性和持久性；

sync_binlog=N；每写入N次二进制日志的事件(不是事务的数量)，mysql会执行一次磁盘同步指令fdatasync()将缓存中的二进制日志刷写到磁盘日志文件中；为了保证数据集的持久性，通常会使用sync_binlog=1，尤其是在MySQL/MariaDB的主从复制架构之中；

二进制日志的大致内容格式：

中继日志：

其内容就是二进制日志的内容；

在主从架构的MySQL集群服务中，从服务器会从主服务器复制二进制日志到本地，将其保存在中继日志中；

二进制日志的格式是二进制格式，中继日志的文件格式为纯文本格式；

与中继日志有关的相关参数：

relay_log = { ON | OFF | PATH }

中继日志功能开关，定义了中继日志存放的路径和文件名称；如果此参数值为空，则默认会将中继日志放置于数据目录中，文件名默认为：HOSTNAME-relay-bin.xxxxxx;

注意：通常需要使用中继日志时，直接定义出文件的路径，而不使用默认值；以防止在主机名被更改之后，无法定位日志文件的位置；

relay_log_recovery = { ON | OFF }

当从服务从宕机状态恢复后，如果中继日志损坏，导致一部分日志中的语句无法被重放或者全部不能被重放，此时是否自动放弃所有未执行的中继日志的内容，并且从主服务器重新获取二进制日志的功能开关；建议开启；

事务日志：

在MySQL或MariaDB系统中，一般就是指InnoDB的事务日志，包含两种日志；

redo log

提供数据重做功能，实现前滚操作；

通常是物理日志；记录的是数据页的物理修改，而不是针对于某一行或某几行的修改结果；

如果使用redo log恢复数据，能恢复到最后一次提交事务后的位置；

undo log

提供数据恢复功能，实现回滚操作：

提供了恢复操作及MVCC功能；undo log中存放的内容是对应的行在被修改之前的内容，或者与修改数据相反的SQL语句；

undo log一般是逻辑日志，根据每行中的数据修改来进行记录，通常存放于逻辑表空间中；

注意：undo log的执行过程并是不会redo log 的逆过程，实际上着两种日志都是用来实现恢复功能的日志；

redo log的第一部分是否能够持久存储，MySQL中通过innodb_flush_log_at_trx_commit服务器参数来进行控制；

innodb_flsuh_log_at_trx_commmit = N 默认是2；

如果该参数取值为1，事务每次提交都会将日志缓存中的日志写入操作系统的缓冲区并立即调用fsync()刷写到"log file on disk"中，这种日志刷写方式即使系统直接崩溃也会丢失任何数据，数据的持久性也可以得到保证；但是每次提交事务都需要写入磁盘，IO性能非常差；

如果该参数为0，事务提交后，不会将事务日志缓存缓冲区中的日志写入操作系统的缓冲区，每秒钟提交给操作系统缓冲区一次并调用fsync()刷写到"log file on disk"中；如果系统崩溃，会丢失一秒内的所有数据；

如果该参数值为2，每次提交事务都直接写入操作系统的缓存，然后由操作系统每秒调用fsync()函数将操作系统缓冲区中的日志内容写入到"log file on disk"中；如果MySQL服务崩溃，不会丢失数据；但如果操作系统崩溃，会丢失一秒内的所有数据；

MariaDB [(none)]> show global variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+

undo log的作用：

1.提供回滚功能；

2.多版本并行控制(MVCC)

在数据被修改时，InnoDB不仅记录的redo log，还记录了undo log；

因此可以在开启事务之后的执行操作过程中，因为某些操作失败或因为某些操作不合理，而借助于undo log进行回滚；

undo log与redo log形式上不同，属于逻辑日志。存放于表空间中；

undo log默认存放在共享表空间中，如果启用了innodb_file_per_table服务器参数，则意味着每个表的独立表空间中均会保存与该表相关的undo log；

MariaDB [(none)]> show global variables like 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+

转载于:https://blog.51cto.com/liujingyu/2157398

weixin_34018202

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
MySQL/MariaDB的日志

在Mysql/MariaDB的日志大致分为下列几种：查询日志一般查询日志：慢查询日志：错误日志二进制日志中继日志事务日志简要介绍一下这几种日志，日志对我们分析MySQL服务有着很重要的帮助；查询日志：一般查询日志：默认关闭，因为会记录所有的查询语句；MariaDB[(none)]>s...
复制链接

扫一扫