MySQL series: innodb source code analysis-redo log recovery, innodbredo

Source: Internet
Author: User

MySQL series: innodb source code analysis-redo log recovery, innodbredo

In the previous "innodb source code analysis-redo log structure", we know the basic structure and log writing steps of the redo log. How does the redo log recover data? When will redo log deduction be performed? Redo log deduction is performed only when the database is abnormal or shut down. When the database is restarted, the log deduction is performed to restore the database status to the State before the database is closed. So how does this process work? The following is a step-by-step analysis.

1. The recv_sys_t structure innodb will redo the log files when MySQL starts. The redo log is restored and controlled through a recv_sys_t structure. Its structure is as follows:
Struct recv_sys_struct {mutex_t mutex;/* Protection lock */ibool apply_log_recs;/* applying log record to page */ibool logs;/* batch applying log record flag */dulint lsn; ulint last_log_buf_size; byte * last_block;/* last block memory buffer during recovery */byte * last_block_buf_start;/* start position of last block memory buffer because last_block is 512 address aligned, this variable is required to record the free address location */byte * buf;/* redo log information data read from the log block */ulint len; /* Valid buf Log Data Length */dulint parse_start_lsn;/* Start parse lsn */dulint scanned_lsn;/* scanned lsn */ulint scanned_checkpoint_no; /* The checkpoint number of the recovery log */ulint recovered_offset;/* the offset of the recovery position */dulint recovered_lsn;/* The restored lsn */dulint limit_lsn; /* The maximum lsn for log recovery. */ibool found_corrupt_log is not used during log redo./* Whether to enable Log Recovery diagnosis */log_group_t * archive_group; mem_heap_t * heap; /* recv sys Memory Allocation Heap, used to manage memory usage during recovery */hash_table_t * addr_hash;/* recv_addr hash table, take space id and page no as the KEY */ulint n_addrs;/* addr_hash contains the number of recv_addr */};
In this structure, the addr_hash hash table is complex. This hash table uses sapce_id and page_no as the hash key, which stores the corresponding records during recovery. After the recovery log is read from the log file, it is parsed into several recv_t and stored in the hash table. After a read and resolution period, Log Recovery writes data in the recv_t in the hash table to ibuf and page. Why do we need to use a hash table? I personally think it is for batch data recovery of the same page, which can reduce random insertion and modification of the page. The following are several data structures related to this process:
/* Data recovery operation set on the corresponding page */struct recv_addr_struct {ulint state;/* status, RECV_NOT_PROCESSED, RECV_BEING_PROCESSED, RECV_PROCESSED */ulint space;/* space ID */ulint page_no; /* page number */UT_LIST_BASE_NODE_T (recv_t) rec_list; hash_node_t addr_hash;};/* current record operation */struct recv_struct {byte type;/* log type */ulint len; /* current record data length */recv_data_t * data;/* current record data list */dulint start_lsn;/* mtr start lsn */dulint end_lsn; /* mtr end lns */UT_LIST_NODE_T (recv_t) rec_list;};/* specific data body */struct recv_data_struct {recv_data_t * next;/* next recv_data_t, the next address is followed by a large block of memory for storing rec body */};
Their memory relationship structure is as follows:
2. In addition to the restored hash table, the LSN relationship in the recv_sys_t log deduction process is closely related to log recovery. The following is an explanation of various lsns: parse_start_lsn the lsn starting from the log redo recovery. If it is restored from the checkpoint, It is equal to checkpoint_lsn. During the restoration process, scanned_lsn stores the recovered logs from the log_sys-> buf resolution block and the log lsn of the recv_sys-> buf. recovered_lsn has restored the data to the page or the log lsn in the log operation storage addr_hash; when the log starts to be restored:
Parse_start_lsn = scanned_lsn = recovered_lsn = checkpoint lsn.
When the log is restored:
Parse_start_lsn = lsn of the checkpoint
Scanned_lsn = recovered_lsn = log_sys-> lsn.
The lsn size relationship during log deduction is as follows:

3. Main interfaces for log recovery and main interface functions for log recovery: recv_recovery_from_checkpoint_start recover data from the latest checkpoint in the redo log Group
Recv_recovery_from_checkpoint_finish
Recv_recovery_from_archive_start recover data from the archive log file
Recv_recovery_from_archive_finish
Recv_reset_logs captures the last segment of the redo log as the starting position of the new redo log, and data may be lost.
Redo log data recovery process (checkpoint method)1. When MySQL is started, the largest LSN last saved is read from the database file.
2. Call recv_recovery_from_checkpoint_start and pass the largest LSN to the function as a parameter.
3. The function will first create a checkpoint log group and read the corresponding checkpoint information.
4. Compare the checkpoint lsn with the input maximum LSN. If they are the same, no logs are restored. If they are not the same, logs are restored.
5. Before recovery is started, the archive archiving status of each log group is synchronized.
6. when the restoration starts, the system first reads 2 MB of log data from the log file to log_sys-> buf, then scans the data of 2 MB to verify its validity, then, the log with the block header removed is placed in recv_sys-> buf. This process is called scan and will change the scanned lsn.
7. After scanning 2 MB of log data, innodb will parse the log mtr operation and execute related mtr functions. If mtr is valid, the corresponding record data is stored in recv_sys-> addr_hash by space page_no as the KEY.
8. After mtr resolution is performed on the scan log data, innodb calls recv_apply_hashed_log_recs to scan the entire recv_sys-> addr_hash, and recover the data on the corresponding page according to the log operations. This process changes recovered_lsn.
9. After completing step 1, the system reads 2 MB of data from the log group file again and jumps to step 6 to continue the corresponding processing until the log file does not have the log data to be restored.
10. After innodb completes the data recovery in the log file, it will call recv_recovery_from_checkpoint_finish to end the log recovery operation, mainly to release some open memory. And process transactions and binlogs.
The above process is as follows:



Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.