Mysql--运维篇--日志管理（毗连层，SQL层，存储引擎层，文件存储层） ...

MySQL提供了多种日志范例，用于记录差别的活动和事件。这些日志对于数据库的管理、故障清除、性能优化和安全审计非常紧张。
一、错误日志 (Error Log)

作用：
记录MySQL服务器启动、运行和制止期间遇到的问题和错误信息。
查看：

• 默认情况下，错误日志的位置可以通过show variables like ‘log_error’;命令来查看。
  
• 或者直接在设置文件（通常是my.cnf或my.ini）中查找log_error变量的值。
  

示例：

1. show variables like 'log_error';

复制代码

运行效果：

找到路径，打开文件：

二、查询日志 (General Query Log)

作用：
记录所有发送到服务器的SQL语句，包罗查询、更新等操纵。它可以资助你相识用户执行了哪些操纵，但开启后会影响性能，因此通常只在调试时使用。
查看：

• 可以通过SHOW VARIABLES LIKE ‘general_log%’;来查看是否启用了查询日志以及它的位置。
  
• 使用SET GLOBAL general_log = ‘ON’;启用查询日志，SET GLOBAL general_log = ‘OFF’;禁用。
  
• 日志内容可以及时查看，比方tail -f /path/to/mysql.log。
  

示例：

1. SHOW VARIABLES LIKE 'general_log%';

复制代码

运行效果：

三、慢查询日志 (Slow Query Log)

作用：
记录那些执行时间超过指定阈值的SQL查询。这对于辨认和优化性能瓶颈非常有用。
查看：

• 使用SHOW VARIABLES LIKE ‘slow_query_log%’;来查抄慢查询日志的状态和位置。
  
• SET GLOBAL slow_query_log = ‘ON’;启用慢查询日志，SET GLOBAL slow_query_log = ‘OFF’;禁用。
  
• 你可以设置long_query_time变量来界说“慢”的标准，默认是10秒，但是可以通过SET GLOBAL long_query_time = N;调整，其中N是你想要的时间秒数。
  
• 还可以使用mysqldumpslow工具或者第三方工具如pt-query-digest来分析慢查询日志。
  

示例：

1. SHOW VARIABLES LIKE 'slow_query_log%';

复制代码

运行效果：

四、二进制日志 (Binary Log, Binlog)

作用：
记录所有对数据库结构或数据进行更改的操纵（DDL和DML），好比INSERT、UPDATE、DELETE等。重要用于复制（Replication）、恢复（Recovery）和审计（Audit）。
查看：

• 使用SHOW BINARY LOGS;
  列出所有的二进制日志文件。
  
• 使用SHOW MASTER STATUS;查看当前正在使用的二进制日志文件。
  
• 使用mysqlbinlog工具读取息争析二进制日志的内容，比方mysqlbinlog /path/to/binlog-file。
  

示例：

1. SHOW BINARY LOGS;

复制代码

运行效果：

五、中继日志 (Relay Log)

作用：
在主从复制环境中，从库会将主库的二进制日志中的事件复制到自己的中继日志中，然后再应用这些事件。这使得从库可以或许与主库保持同步。
查看：

• 使用SHOW SLAVE STATUS;可以查看有关从库状态的信息，包罗中继日志的文件名和位置。
  
• 类似于二进制日志，可以使用mysqlbinlog工具来查看中继日志的内容。
  

六、重做日志 (InnoDB Redo Log)

1、概述

重做日志是InnoDB用于确保事件持久性的关键组件。它记录了所有对数据页的物理修改操纵，确保在体系崩溃后可以重新应用这些修改，恢复数据的同等性。
特点：

• 位置：重做日志文件通常位于ib_logfile0和ib_logfile1中。
  
• Redo日志不是文本格式的日志，不能直接查看其内容。
  
• 巨细：每个重做日志文件的巨细由innodb_log_file_size参数控制，默认值为48MB。
  
• 数目：可以通过innodb_log_files_in_group参数指定重做日志文件的数目，默认为2。
  

2、工作原理

（1）、记录修改：每当对数据页进行修改时，InnoDB会先将修改操纵记录到重做日志中。重做日志记录的是物理修改，而不是逻辑操纵。
（2）、循环写入：重做日志采用循环写入的方式。当一个日志文件写满后，InnoDB会切换到下一个日志文件继续写入。所有日志文件写满后，InnoDB会回到第一个日志文件，覆盖旧的日志记录。
（3）、查抄点（Checkpoint）：为了防止重做日志被无限期地循环覆盖，InnoDB使用查抄点机制。查抄点是指重做日志的某个位置，所有在此之前修改的数据页都必须已经刷新到磁盘。通过这种方式，InnoDB可以确保在体系崩溃后可以或许从查抄点开始恢复数据。
（4）、崩溃恢复：在体系崩溃后，InnoDB会在启动时读取重做日志，重新应用未完成的事件，恢复数据的同等性。这个过程称为前滚恢复（Roll Forward Recovery）。
3、设置参数

innodb_log_file_size：

• 功能：设置每个重做日志文件的巨细。
  
• 推荐值：建议根据工作负载调整。对于高并发写入场景，可以恰当增大该值，以减少日志切换的频率。默认值为48MB。
  

innodb_log_files_in_group：

• 功能：设置重做日志文件的数目。
  
• 推荐值：默认为2，通常不需要调整。如果需要更大的日志空间，建议增加单个日志文件的巨细，而不是增加日志文件的数目。
  

innodb_flush_log_at_trx_commit：

• 功能：控制事件提交时是否立即刷新重做日志到磁盘。
  
• 取值：
  
  
  
  • 0：不刷新重做日志，性能最好，但安全性最低。如果体系崩溃，可能会丢失最近的事件。
    
  • 1（默认）：每次事件提交时都刷新重做日志到磁盘，确保数据的安全性，但性能稍差。
    
  • 2：每次事件提交时将重做日志写入操纵体系缓存，但不立即刷新到磁盘。恰当追求性能的场景，但在体系崩溃时可能会丢失最近的事件。
    
  
  

innodb_log_buffer_size：

• 功能：设置重做日志缓冲区的巨细。重做日志缓冲区用于暂存尚未写入磁盘的重做日志记录。
  
• 推荐值：默认为8MB，可以根据工作负载恰当调整。较大的缓冲区可以减少磁盘I/O次数，提拔写性能。
  

4、优化建议

• 增大innodb_log_file_size：对于高并发写入场景，建议增大重做日志文件的巨细，以减少日志切换的频率。较大的日志文件可以容纳更多的事件，减少磁盘I/O次数。
  
• 调整innodb_flush_log_at_trx_commit：根据应用场景选择符合的值。如果你的应用对数据安全要求较高，建议保持默认值1；如果你的应用对性能要求较高，且可以容忍少量数据丢失，可以选择2或0。
  
• 使用O_DIRECT刷新方法：通过innodb_flush_method = O_DIRECT设置，绕过操纵体系的缓存，直接将重做日志写入磁盘，减少双重缓存问题，提拔性能。
  

七、回滚日志 (InnoDB Undo Log)

1、概述

回滚日志是InnoDB用于实现事件的回滚和多版本并发控制（MVCC）的关键组件。它记录了事件的旧版本数据，确保未提交的事件不会影响数据库的状态，并支持多个事件同时读取差别的数据版本。
作用：Undo日志保存了旧版本的数据，以便在需要时回滚事件或提供多版本并发控制（MVCC）。这对于包管事件的ACID特性至关紧张。
特点：

• 位置：回滚段存储在体系UNDO表空间中，通常是ibdata1文件的一部分。
  
• 和Redo日志一样，Undo日志也不是以文本形式存储的，所以不能直接查看。
  
• 范例：
  
• 插入回滚段：用于记录插入操纵的旧版本数据。
  
• 更新回滚段：用于记录更新操纵的旧版本数据。
  

2、工作原理

（1）、记录旧版本数据：每当对数据进行插入、更新或删除操纵时，InnoDB会将旧版本数据记录到回滚日志中。这些旧版本数据用于实现事件的回滚和多版本并发控制（MVCC）。
（2）、事件回滚：如果事件未提交或发生错误，InnoDB可以根据回滚段中的旧版本数据，将数据恢复到事件开始时的状态。
（3）、多版本并发控制（MVCC）：InnoDB使用回滚段来支持多版本并发控制。当多个事件同时读取同一行数据时，InnoDB会根据事件的隔离级别返回符合的数据版本。比方，在读已提交（Read Committed）隔离级别下，事件只能看到已经提交的数据；而在可重复读（Repeatable Read）隔离级别下，事件在整个生命周期内都能看到雷同的数据版本。
（4）、清算旧版本数据：当事件提交后，回滚段中的旧版本数据不再需要，InnoDB会定期清算这些数据，释放空间。
3、设置参数

innodb_undo_tablespaces：

• 功能：设置独立的回滚表空间的数目。启用该参数后，回滚段将存储在独立的.ibd文件中，而不是体系表空间中。（表空间中包含三种范例：数据，索引，回滚段）
  
• 推荐值：默认为0，表示回滚段存储在体系表空间中。如果你有大量长时间运行的事件，建议启用独立的回滚表空间，以减少体系表空间的碎片化问题。
  

innodb_undo_log_truncate：

• 功能：控制是否定期截断回滚段。启用该参数后，InnoDB会定期清算不再需要的回滚段，释放空间。
  
• 推荐值：默认为OFF，建议在生产环境中启用该参数，以减少回滚段的占用空间。
  

innodb_max_undo_log_size：

• 功能：设置回滚段的最大巨细。当回滚段超过该巨细时，InnoDB会自动截断回滚段，释放空间。
  
• 推荐值：默认为1GB，可以根据工作负载恰当调整。
  

4、优化建议

• 启用独立回滚表空间：如果你有大量长时间运行的事件，建议启用独立的回滚表空间，以减少体系表空间的碎片化问题。独立的回滚表空间可以更好地管理和优化回滚段的存储。
  
• 定期截断回滚段：启用innodb_undo_log_truncate参数，定期清算不再需要的回滚段，释放空间。这有助于减少回滚段的占用空间，提拔性能。
  
• 调整回滚段巨细：根据工作负载调整innodb_max_undo_log_size参数，确保回滚段不会占用过多的空间。对于大事件或长事件较多的场景，可以恰当增大该值。
  

八、审计日志 (Audit Log)

作用：
记任命户的登录实验、权限变更和其他安全干系的活动。并不是所有版本的MySQL都自带审计日志功能，某些企业版可能包含这个特性，或者可以通过插件实现。
查看：

• 如果安装了审计插件，可以通过特定的命令或API来访问审计日志。
  
• 详细的查看方法取决于所使用的插件或办理方案。
  

乘风破浪会偶然，直挂云帆济沧海！！！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。