Co-purchase source building and MySQL Engine Features

First Order
In this paper, according to the 11th chapter of MySQL operation and control InnoDB Log management mechanism, this book focuses on the principle of log generation, format, working principle, brush disk mechanism. Space-constrained, crash-recovery needs to be collated separately. InnoDB has two very important logs, one is undo log, the other is redo log, which is used to guarantee the atomicity of the transaction and the MVCC of InnoDB, which is used to ensure the persistence of the transaction. Explain the Redolog and transactional persistence: Redo log is used for data recovery and database restart when the page data is restored synchronously, redo log is based on mini transaction. When the database executes a transaction, the minitransaction generates redo log to guarantee the persistence of the transaction. Co-buy source building qq:2152876294 URL diguaym.com

 和大多数关系型数据库一样，InnoDB记录了对数据文件的物理更改，并保证总是日志先行，也就是所谓的WAL(log write ahead)，即在持久化数据文件前，保证之前的redo日志已经写到磁盘。  LSN(log sequence number) 用于记录日志序号，它是一个不断递增的 unsigned long long 类型整数。在 InnoDB 的日志系统中，LSN 无处不在，它既用于表示修改脏页时的日志序号，也用于记录checkpoint，通过LSN，可以具体的定位到其在redo log文件中的位置。LSN在引擎中定义的是一个dulint_t类型值。源码在innobase/include/log0log.h

/ Type used for all log sequence number storage and arithmetics /
typedef ib_uint64_t LSN_T;
The LSN means the amount of log (bytes) written by the storage engine to the redo log system, which includes the log bytes written + log_block_hdr_size + log_block_trl_size; code See functions Log_write_ Low (source code in innobase/log/log0log.cc). In the call log write function LSN has been increasing with the length of the log written, it is a set of physical meaning and logical meaning and integration.

  为了管理脏页，在 Buffer Pool 的每个instance上都维持了一个flush list，flush list 上的 page 按照修改这些 page 的LSN号进行排序。因此定期做redo checkpoint点时，选择的 LSN 总是所有 bp instance 的 flush list 上最老的那个page（拥有最小的LSN）。由于采用WAL的策略，每次事务提交时需要持久化 redo log 才能保证事务不丢。而延迟刷脏页则起到了合并多次修改的效果，避免频繁写数据文件造成的性能问题。   innodb在5.6设计了3个层模块，即redo log buffer（redo log的日志内存缓冲区）、group files( redo log文件组)和archive files( 归档日志文件)。由于 InnoDB 日志组的特性已经被废弃（redo日志写多份），归档日志(archive log)特性也在5.7被彻底移除，所以不做展开。

Well, even though it's all common sense, it's about understanding the first contact. Because Baidu comes out of the article is not necessarily based on that version.

Two InnoDB log files
The redo log of InnoDB can be configured as multiple files through the parameter Innodb_log_files_in_group, and the other parameter innodb_log_file_size represents the size of each file. So the total redo log size is Innodb_log_files_in_group * innodb_log_file_size.
The Redo log file is named Ib_logfile[number] and the log directory can be controlled by parameter innodb_log_group_home_dir. The Redo log is written sequentially to the file file, which goes back to the first file when it is full, overwriting

  在InnoDB内部，逻辑上ib_logfile被当成了一个文件，对应同一个space id。由于是使用512字节block对齐写入文件，可以很方便的根据全局维护的LSN号计算出要写入到哪一个文件以及对应的偏移量。   Redo log文件是循环写入的，在覆盖写之前，总是要保证对应的脏页已经刷到了磁盘。在非常大的负载下，Redo log可能产生的速度非常快，导致频繁的刷脏操作，进而导致性能下降，通常在未做checkpoint的日志超过文件总大小的76%之后，InnoDB 认为这可能是个不安全的点，会强制的preflush脏页，导致大量用户线程stall住。除了redo log文件外，InnoDB还有其他的日志文件，例如为了保证truncate操作而产生的中间日志文件，包括 truncate innodb 表以及truncate undo log tablespace，都会产生一个中间文件，来标识这些操作是成功还是失败，如果truncate没有完成，则需要在 crash recovery 时进行重做。

Log Block

Co-purchase source building and MySQL Engine Features