前言：

昨晚，突然出现服务不可用告警，查看日志上线报文入库到数据库很慢并受阻，出现数据不同步问题。

排查问题

查看发现服务都是在执行update、insert这些DML命令的时候，报的数据库执行超时。经过一系列的分析发现由于服务器资源不足导致的。

问题由于数据库一直在服务，binlog日志记录的DML和DDL的操作都会被记录下来，日积月累，binlog日志竟然比mysql数据文件所占用的空间还多。binlog日志变大导致占用资源比较多出现资源不足问题。

下面我们说说mysql的三个日志文件。

undo log、redo log以及binlog

在MySQL数据库中，binlog、redolog和undolog都是日志类型文件，但它们各自的作用和实现方式有所不同。

binlog主要用来对数据库进行数据备份、崩溃恢复和数据复制等操作，redolog和undolog主要用于事务管理，记录的是数据修改操作和回滚操作。redolog用来做恢复，undolog用来做回滚。

在MySQL中，redolog和undolog只适用于InnoDB存储引擎，因为要支持事务。而不适用于MyISAM等其他存储引擎。而binlog则适用于所有存储引擎。

binlog是MySQL用于记录数据库中的所有DDL语句和DML

语句的一种二进制日志。它记录了所有对数据库结构和数据的修改操作，如INSERT、UPDATE和DELETE等。binlog主要用来对数据库进行数据备份、灾难恢复和数据复制等操作。binlog的格式分为基于语句的格式和基于行的格式。

例子：继续上面的转账操作例子，当事务成功提交后，MySQL会将这个转账操作（包括账户A的扣款和账户B的加款）记录到binlog中。如果数据库发生故障，管理员可以使用binlog来恢复数据；同时，在MySQL的主从复制环境中，从服务器会读取主服务器上的binlog来同步数据。

Redo Log是MySQL用于实现崩溃恢复和数据持久性的一种机制。在事务进行过程中MySQL会将事务做了什么改动到Redo Log中。当系统崩溃或者发生异常情况时，MySQL会利用Redo Log中的记录信息来进行恢复操作，将事务所做的修改持久化到磁盘中。

例子：还是以转账操作为例，当InnoDB存储引擎更新账户A和账户B的余额时，这些更新操作会先写入redo log中。即使数据库在更新过程中崩溃，只要redo log没有损坏，MySQL就可以在重启后通过重放redo log中的操作来恢复数据，确保数据的持久性。

Undo Log则用于在事务回滚或系统崩溃时撤销(回滚)事务所做的修改。当一个事务执行过程中，MySQL会将事务修改前的数据记录到Undo Log中。如果事务需要回滚，则会从Undo Log中找到相应的记录来撤销事务所做的修改。另外，ndoLog还支持MVCC(多版本并发控制)机制，用于在并发事务执行时提供一定的隔离性。

例子：假设有一个转账操作，从账户A转账100元到账户B。在事务提交前，MySQL会记录账户A和账户B在转账前的余额到undo log中。如果转账过程中发生错误或需要回滚，MySQL会根据undo log中的记录，将账户A和账户B的余额恢复到转账前的状态。

三个日志文件大小

在MySQL中，哪个日志文件会比较大，这个问题并没有一个绝对的答案，因为它取决于多种因素，包括数据库的负载、事务的频繁程度、配置参数的设置等。根据一般情况和其它参考文章中的信息，对这三个日志文件（undo_log、binlog、redo log）的大小进行一些分析和归纳。

binlog（二进制日志）

大小因素：binlog记录了数据库中所有的DDL和DML语句（除了SELECT和SHOW），因此它的大小可能会随着数据库活动的增加而迅速增长。特别是当数据库中存在大量数据更新操作时，binlog会迅速变大。

• 配置参数：max_binlog_size参数可以控制单个binlog文件的大小，当文件达到这个大小时，会自动切换到下一个文件。但是，这并不意味着binlog的总体大小会受到限制，因为随着数据库活动的持续进行，会不断产生新的binlog文件。
• 过期时间：binlog_expire_logs_seconds参数可以设置binlog文件的过期时间，超过这个时间的binlog文件会被自动删除，但这需要管理员手动执行清理操作或配置相应的自动清理机制。

redo log（重做日志）

大小因素：redo log的大小通常是由配置参数innodb_log_file_size决定的，每个redo log文件的大小是固定的。但是，MySQL允许配置多个redo log文件组成一个redo log组（innodb_log_files_in_group参数），以支持更大的日志空间。

• 循环使用：当redo log文件被写满后，MySQL会开始覆盖最旧的日志记录，以实现日志的循环使用。这意味着redo log的大小虽然受到配置参数的限制，但在实际使用中，其占用的磁盘空间并不会持续增加。

undo_log（回滚日志）

大小因素：undo_log的大小主要取决于事务的频繁程度和每个事务中修改的数据量。如果事务非常频繁，且每个事务修改的数据量很大，那么undo_log可能会占用较多的空间。

• 空间回收：MySQL会定期通过purge线程来清理不再需要的undo日志，以释放空间。因此，undo_log的大小并不会无限制地增长。

总结

线上问题是由于binlog日志太大了，没有通过参数配置binlog的日志大小和过期时间，导致服务器磁盘硬件资源不足，导致服务不可用，数据库操作受阻。