1 Mysql日志分类 mysql 的日志分为两部分: Server层的日志,所有引擎共享 Engine层日志,本文只说明 InnoDB 引擎日志 2 Server 层日志 2.1 错误日志 Mysql的err
mysql 的日志分为两部分:
Mysql的error log用于记录错误信息的log,但error记录的不仅仅是错误信息,有关服务进程的错误信息也会被记录(critical级别);如果mysqld进程发现某些表需要自动检查或者修复的话,也会抛出相关信息到该log。
配置方法:
[mysqld_safe]
log-error=/var/lib/mysql/mysql.err
查看当前配置:
mysql> show variables like "log_error";
+---------------+-----------------------------------+
| Variable_name | Value |
+---------------+-----------------------------------+
| log_error | /home/mysql-server/log/mysqld.log |
+---------------+-----------------------------------+
1 row in set (0.04 sec)
当语句执行时间较长时,通过日志的方式进行记录,这种方式就是慢查询的日志。默认情况下,MySQL数据库并不启动慢查询日志,你需要手工将slow_query_log
参数设为ON,然后启动。
影响慢查询的参数:
参数名称 | 说明 |
---|---|
slow_query_log | 慢查询开关,OFF / ON |
long_query_time | 超过多少秒的查询写入日志,单位:秒 |
log_output | 存储方式,file: 文件 / table: 表(mysql.slow_log) / none:不存储 |
slow_query_log_file | 慢查询日志文件路径 |
log_queries_not_using_indexes | 如果值设置为ON,则会记录所有没有利用索引的查询 |
查看当前配置:
mysql> show variables where variable_name in ("slow_query_log", "long_query_time", "log_output", "slow_query_log_file", "log_queries_not_using_indexes");
+-------------------------------+--------------------------------------+
| Variable_name | Value |
+-------------------------------+--------------------------------------+
| log_output | FILE |
| log_queries_not_using_indexes | OFF |
| long_query_time | 10.000000 |
| slow_query_log | OFF |
| slow_query_log_file | /var/lib/mysql/b9cdf147d7ea-slow.log |
+-------------------------------+--------------------------------------+
5 rows in set (0.01 sec)
配置方法:
set global slow_query_log = "on";
即可。此方法在数据库重启后失效。MySQL的查询日志记录了所有MySQL数据库请求的信息。无论这些请求是否得到了正确的执行。默认文件名为hostname.log。默认情况下MySQL查询日志是关闭的。生产环境,如果开启MySQL查询日志,对性能还是有蛮大的影响的。另外很多时候,MySQL慢查询日志基本可以定位那些出现性能问题的SQL,所以MySQL查询日志应用的场景其实不多,有点鸡肋的感觉。
查看当前配置:
mysql> show variables like "%general_log%";
+------------------+------------------------------+
| Variable_name | Value |
+------------------+------------------------------+
| general_log | OFF |
| general_log_file | /var/lib/mysql/DB-Server.log |
+------------------+------------------------------+
2 rows in set (0.00 sec)
二进制日志记录了对数据库执行更改的所有操作,但是不包括SELECT和SHOW这类操作,因为这类操作对数据本身并没有修改,如果你还想记录SELECT和SHOW操作,那只能使用查询日志,而不是二进制日志了。此外,二进制还包括了执行数据库更改操作的时间和执行时间等信息。
二进制日志主要有以下两种作用:
影响 binlog 的参数:
参数名称 | 说明 |
---|---|
log_bin | 二进制日志开关 OFF / ON |
log_bin_basename | 主文件名称 |
log_bin_index | 轮询文件名称 |
bin_log_fORMat | 日志模式:statement(基于语句) / row(基于行) / mixed(混合) |
sync_binlog | 每写缓冲多少次就同步到磁盘。如果设为1,表示采用同步写磁盘的方式来写二进制日志,这时写操作不使用操作系统的缓冲来写二进制日志,如果是事务性的引擎,本身就是为了保证事物安全的,没理由不把sync_binlog 设置为1 |
max_bin_log_size | 单个日志文件最大值(字节),超过该值,则产生新日志文件,后缀名+1,并记录到.index文件 |
expire_logs_days | 二进制日志滚动之后会生成新的文件来存储日志,日志文件逾期之后会自动删除,否则会产生源源不断的日志文件 |
binlog_cache_size | 二进制日志的缓存,当事物开始的时候,会按照binlog_cache_size系统变量指定的值分配内容空间,如果指定的binlog_cache_size缓存空间不够则会报错并回滚事物,单位:字节,默认:32K。基于会话,当一个线程开始一个事务时,MySQL会自动分配一个大小为binlog_cache_size的缓存 |
max_binlog_cache_size | 实例级别的二进制日志缓存,如果并发量很大,就需要考虑将max_binlog_cache_size设置的稍微大一些 |
查看当前配置:
mysql> show variables where variable_name in
("log_bin", "log_bin_basename", "log_bin_index", "bin_log_format", "sync_binlog", "max_bin_log_size", "expire_logs_days", "binlog_cache_size", "max_binlog_cache_size");
+-----------------------+-------------------------------------------+
| Variable_name | Value |
+-----------------------+-------------------------------------------+
| binlog_cache_size | 32768 |
| expire_logs_days | 97 |
| log_bin | ON |
| log_bin_basename | /home/mysql-server/binlog/mysql-bin |
| log_bin_index | /home/mysql-server/binlog/mysql-bin.index |
| max_binlog_cache_size | 18446744073709547520 |
| sync_binlog | 1 |
+-----------------------+-------------------------------------------+
7 rows in set (0.04 sec)
redo log 与 binlog 这两种日志有以下三点不同:
影响 redo log 的参数
参数名称 | 说明 |
---|---|
innodb_log_files_in_group | 一组 redo log 有几个文件 |
innodb_log_file_size | 组内每个文件的大小(字节) |
innodb_log_group_home_dir | 文件的路径,默认在 data 目录下 |
innodb_log_buffer_size | 日志内存缓冲大小,事务提交前记录在这里 |
innodb_flush_log_at_trx_commit | 将buffer刷入log文件的时机, 0:事务提交时不会写buffer到os buffer,而是每秒刷buffer到os buffer并调fsync刷到磁盘中,当系统崩溃,会丢失1秒钟的数据。 1:事务提交时写buffer到os buffer同时调fsync刷到磁盘,系统崩溃不会丢数据,但每次刷磁盘,IO性能较差。 2:事务提交时写buffer到os buffer,然后每秒调用fsync刷磁盘。 |
查看当前配置:
mysql> show variables like "innodb_%log%";
+----------------------------------+------------+
| Variable_name | Value |
+----------------------------------+------------+
| innodb_api_enable_binlog | OFF |
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_log_buffer_size | 16777216 |
| innodb_log_checksums | ON |
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 50331648 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_log_write_ahead_size | 8192 |
| innodb_max_undo_log_size | 1073741824 |
| innodb_online_alter_log_max_size | 134217728 |
| innodb_redo_log_encrypt | OFF |
| innodb_undo_log_encrypt | OFF |
| innodb_undo_log_truncate | ON |
+----------------------------------+------------+
15 rows in set (0.01 sec)
redo log 写入过程:
打开binlog选项后,执行事务提交命令时,就会进入两阶段提交模式。日志写入时机与前文介绍过的innodb_flush_log_at_trx_commit
和sync_binlog
参数配置有关,“双1模式”的过程如下:
mysqld 可能在任何情况下crash,os也有可能出现问题,另外若机器掉电,mysqld也会同样挂掉。但是即使这样,mysql仍然能保证数据库的一致性。接下来,结合上述流程,分析二阶段提交如何保证这点的。下面给出几种常见的场景:
--结束END--
本文标题: MySQL 日志文件简介
本文链接: https://www.lsjlt.com/news/6337.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
下载Word文档到电脑,方便收藏和打印~
2024-03-16
2024-03-15
2024-03-15
2024-03-15
2024-03-15
2024-03-15
2024-03-15
2024-03-15
2024-03-15
2024-03-14
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0