InnoDB source code analysis-transaction log (2), innodb source code

InnoDB source code analysis-transaction log (2), innodb source code

Original article, reproduced please indicate the original link: http://www.cnblogs.com/wingsless/p/5708992.html

Yesterday I wrote some basic points about the transaction log (http://www.cnblogs.com/wingsless/p/5705314.html), today combined with my recent learning results continue to summarize the knowledge of the transaction log.

3. log structure

We all know that the smallest storage unit of InnoDB is page or block. The same is true for the log system. It is a 512-byte block and is defined by this parameter: OS _FILE_LOG_BLOCK_SIZE.

A block is certainly not as simple as storing data. It must have some information written in the header and tail, which can be easily found in the Code:

/* Offsets of a log block header */#define    LOG_BLOCK_HDR_NO    0    /* block number which must be > 0 and                    is allowed to wrap around at 2G; the                    highest bit is set to 1 if this is the                    first log block in a log flush write                    segment */#define LOG_BLOCK_FLUSH_BIT_MASK 0x80000000UL                    /* mask used to get the highest bit in                    the preceding field */#define    LOG_BLOCK_HDR_DATA_LEN    4    /* number of bytes of log written to                    this block */#define    LOG_BLOCK_FIRST_REC_GROUP 6    /* offset of the first start of an                    mtr log record group in this log block,                    0 if none; if the value is the same                    as LOG_BLOCK_HDR_DATA_LEN, it means                    that the first rec group has not yet                    been catenated to this log block, but                    if it will, it will start at this                    offset; an archive recovery can                    start parsing the log records starting                    from this offset in this log block,                    if value not 0 */#define LOG_BLOCK_CHECKPOINT_NO    8    /* 4 lower bytes of the value of                    log_sys->next_checkpoint_no when the                    log block was last written to: if the                    block has not yet been written full,                    this value is only updated before a                    log buffer flush */#define LOG_BLOCK_HDR_SIZE    12    /* size of the log block header in                    bytes */

/* Offsets of a log block trailer from the end of the block */#define    LOG_BLOCK_CHECKSUM    4    /* 4 byte checksum of the log block                    contents; in InnoDB versions                    < 3.23.52 this did not contain the                    checksum but the same value as                    .._HDR_NO */#define    LOG_BLOCK_TRL_SIZE    4    /* trailer size in bytes */

 

Draw a picture:

The header length is 12 bytes, and the tail length is 4 bytes. The code indicates the length of the header and tail, and all others are offsets. Therefore, the length of each part is the next offset minus the current value. In this case, the part of data that can be stored is actually only 496 bytes. This part of the online materials is called log data, so do I.

What I think is interesting in the header is this: LOG_BLOCK_FIRST_REC_GROUP, which is the offset of the start position of the first log in the block. For example, if a log contains 500 bytes, after writing a block, four bytes will be written in the next block, at this time, a 100-byte page is written into the second block (named log2), so the second block becomes like this:

The second log starts from the 16 position and ends at the 116 position. What will be written in the value of LOG_BLOCK_FIRST_REC_GROUP at this time? Apparently it is 16, because log2 is the first page in the block.

Knowing the log structure is actually the first step in understanding redo log, because redo log is an important means for InnoDB to implement transactions, and the water in it is very deep, I will keep writing my learning experience here, and constantly add the written content.

Original article, reproduced please indicate the original link: http://www.cnblogs.com/wingsless/p/5708992.html