mysql 清理 reley_MySQL日志管理

概述

MySQL提供了丰富的日志

事务日志：transaction log

事务日志的写入类型为“追加”，因此其操作为“顺序IO”；通常也被称为：预写式日志 write ahead logging

事务日志文件： ib_logfile0， ib_logfile1

错误日志 error log

通用日志 general log

慢查询日志 slow query log

二进制日志 binary log

中继日志 reley log，在主从复制架构中，从服务器用于保存从主服务器的二进制日志中读取的事

件

事务日志

事务日志：transaction log

事务型存储引擎自行管理和使用，建议和数据文件分开存放，redo log和undo log

Innodb事务日志相关配置：

show variables like '%innodb_log%';

SELECT * FROM information_schema.INNODB_TRX;

innodb_log_file_size 50331648 每个日志文件大小

innodb_log_files_in_group 2 日志组成员个数

innodb_log_group_home_dir ./ 事务文件路径

innodb_flush_log_at_trx_commit 默认为1

事务日志性能优化

如果发现数据库特别慢，可以修改这个flush这个值，从1修改为2.

事务日志是不能永久保存数据的。

innodb_flush_log_at_trx_commit=0|1|2

追求高性能用1

安全用0和2

2把数据放操作系统缓冲区，兼顾性能和安全性

1 此为默认值，日志缓冲区将写入日志文件，并在每次事务后执行刷新到磁盘。 这是完全遵守ACID特性

0 提交时没有写磁盘的操作; 而是每秒执行一次将日志缓冲区的提交的事务写入刷新到磁盘。 这样可提供

更好的性能，但服务器崩溃可能丢失最后一秒的事务

2 每次提交后都会写入OS的缓冲区，但每秒才会进行一次刷新到磁盘文件中。 性能比0略差一些，但操作系

统或停电可能导致最后一秒的交易丢失

高并发业务行业最佳实践，是使用第三种折衷配置(=2)：

1.配置为2和配置为0，性能差异并不大，因为将数据从Log Buffe