MySQL redo

标签：MySQL 标签：MySQL结构 标签：MySQL redo Redo log 相关结构和记入过程： 1. log_sys对象 (1). log_sys作用 log_sys是redo日志系统的关键全局变量。负责三项事情： log record从mtr_buf复制到logbuffer： 用户线程mtr_commit时，将mtr_buf中的redo record，拷贝到log buffer中； log record从log buffer复制到logfile：write_mutex控制logbuffer顺序的刷盘； dirty page从buffer pool刷写到datafile：log_flush_order_mutex控制flushlist的顺序刷盘；执行CHECKPOINT或preflush。 其中，三个锁分别控制 log_t互斥访问(mutex)、 日志刷盘(write_mutex)、 数据刷盘(log_flush_order_mutex)的操作。 (2). 与日志组、日志相关变量 ulint n_files：Ib_logfile的文件个数。 lsn_t file_size：文件大小。 ulint space_id：Redo log 的space id, 固定大小，值为SRV_LOG_SPACE_FIRST_ID。 ulint state：LOG_GROUP_OK 或者 LOG_GROUP_CORRUPTED。 lsn_t lsn：该group内写到的lsn。 lsn_t lsn_offset：上述lsn对应的文件偏移量。在log_group_t里的lsn和lsn_offset字段已经记录了某个日志lsn和其存放在文件内的偏移量之间的对应关系。                    计算时需要结合LOG_FILE_START_LSN，判断是否跨了logfile文件。 byte** file_header_bufs：       Buffer区域，用于设定日志文件头信息，并写入ib logfile。当切换到新的ib_logfile时，更新该文件的起始lsn，写入头部。        头部信息还包含： LOG_GROUP_ID, LOG_FILE_START_LSN（当前文件起始lsn）、LOG_FILE_WAS_CREATED_BY_HOT_BACKUP(函数log_group_file_header_flush)。 lsn_t scanned_lsn：用于崩溃恢复时辅助记录扫描到的lsn号。 byte* checkpoint_buf：       Checkpoint缓冲区，用于向日志文件写入checkpoint信息（下文详细描述）。       只有做完checkpoint后，其之前的日志才可以不再保留，否则系统崩溃时则无法恢复。在系统崩溃后的恢复，需要从checkpoint点开始。       但我们需要把checkpoint的相关信息持久化的保存下来，才能在系统崩溃时不会丢失这些检查点相关的信息。Checkpoint相关的信息只存放在ib _logfile0中。      lsn_t write_lsn:最近一次完成写入到文件的LSN。 lsn_t current_flush_lsn：当前正在fsync到的LSN。 lsn_t flushed_to_disk_lsn：最近一次完成fsync到文件的LSN。        innodb_log_files_in_group=4 innodb_log_file_size=4G 总文件大小: 17179869184 log_sys->max_modified_age_async = 12175607164 (71%) log_sys->max_modified_age_sync = 13045293390 (76%) log_sys->max_checkpoint_age_async = 13480136503 (78%) log_sys->max_checkpoint_age = 13914979615 (81%) 当当前未刷脏的最老lsn和当前lsn的距离超过max_modified_age_async（71%）时，且开启了选项innodb_adaptive_flushing时，page cleaner线程会去尝试做更多的dirty page flush工作，避免脏页堆积。 当当前未刷脏的最老lsn和当前Lsn的距离超过max_modified_age_sync(76%)时，用户线程需要去做同步刷脏，这是一个性能下降的临界点，会极大的影响整体吞吐量和响应时间。 当上次checkpoint的lsn和当前lsn超过max_checkpoint_age(81%)，用户线程需要同步地做一次checkpoint，需要等待checkpoint写入完成。 当上次checkpoint的lsn和当前lsn的距离超过max_checkpoint_age_async（78%）但小于max_checkpoint_age（81%）时，用户线程做一次异步checkpoint（后台异步线程执行CHECKPOINT信息写入操作），无需等待checkpoint完成。        (3). 与redo log 内存缓冲区相关的成员变量： 变量名描述 ulint buf_size：Log buffer 大小，受参数innodb_log_buffer_size控制，但可能会自动extend。 byte* buf：Log buffer起始位置指针。 ulint buf_free：Log buffer中当前空闲可写的位置。redo record可拷贝写入的buffer的位置（buf_free）。 ulint max_buf_free：值为log_sys->buf_size / LOG_BUF_FLUSH_RATIO - LOG_BUF_FLUSH_MARGIN.                      其中： LOG_BUF_FLUSH_RATIO=2, LOG_BUF_FLUSH_MARGIN=(4 * 512 + 4* page_size),page_size默认为16k.                      当buf_free超过该值时，可能触发用户线程去写redo；在事务拷redo record到buffer后，也会判断该值，如果超过buf_free，设置log_sys->check_flush_or_checkpoint为true。 ulint buf_next_to_write：Log buffer偏移量，下次写入redo log文件的起始位置，即本次写入的结束位置。redo缓冲区将要向磁盘刷盘的位置（buf_next_to_write） volatile bool is_extending：Log buffer是否正在进行扩展 （防止过大的redo log entry无法写入buffer）, 实际上，当写入的redo log长度超过buf_size/2时，就会去调用函数log_buffer_extend,一旦扩展Buffer，就不会在缩减回去了！ ulint write_end_offset：本次写入的结束位置偏移量(从逻辑来看有点多余，直接用log_sys->buf_free就行了)。       (4). 和Checkpoint检查点相关的成员变量： 变量名描述 ib_uint64_t next_checkpoint_no:每完成一次checkpoint递增该值。 lsn_t last_checkpoint_lsn:最近一次checkpoint时的lsn，每完成一次checkpoint，将next_checkpoint_lsn的值赋给last_checkpoint_lsn。 lsn_t next_checkpoint_lsn:下次checkpoint的lsn（本次发起的checkpoint的lsn）。 mtr_buf_t* append_on_checkpoint:             5.7新增，在做DDL时（例如增删列），会先将包含MLOG_FILE_RENAME2日志记录的buf挂到这个变量上。              在DDL完成后，再清理掉。(log_append_on_checkpoint),主要是防止DDL期间crash产生的数据词典不一致。  ulint n_pending_checkpoint_writes:大于0时，表示有一个checkpoint写入操作正在进行。用户发起checkpoint时，递增该值。后台线程完成checkpoint写入后，递减该值(log_io_complete) rw_lock_t checkpoint_lock:checkpoint锁，每次写checkpoint信息时需要加x锁。由异步io线程释放该x锁 byte* checkpoint_buf:Checkpoint信息缓冲区，每次checkpoint前，先写该buf，再将buf刷到磁盘。 2. 日志文件头 每个日志文件的前2048字节是存放的文件头信息。 其中几个重要的字段在这里加以说明： 日志文件头共占用4个OS_FILE_LOG_BLOCK_SIZE的大小,即2KB。这里对部分字段做简要介绍： 1) LOG_GROUP_ID               这个log文件所属的日志组，占用4个字节，当前都是0； 2) LOG_FILE_START_LSN     这个log文件记录的开始日志的lsn，占用8个字节； 3) LOG_FILE_WAS_CRATED_BY_HOT_BACKUP   备份程序所占用的字节数，共占用32字节； 4) LOG_CHECKPOINT_1/LOG_CHECKPOINT_2   两个记录InnoDB checkpoint信息的字段，分别从文件头的第二个和第四个block开始记录，只使用日志文件组的第一个日志文件。 从地址2KB偏移量开始，其后就是顺序写入的各个日志块（log block）。 3. 日志块日志块结构所有的redo日志记录是以日志块为单位组织在一起的，日志块的大小为OS_FILE_LOG_BLOCK_SIZE（默认值为512字节），所有的日志记录以日志块为单位顺序写入日志文件。每一条记录都有自己的LSN（log sequence number， 表示从日志记录创建开始到特定的日志记录已经写入的字节数）。每个日志块包含一个日志头段（12字节）、一个尾段（4字节），以及一组日志记录（512 – 12 – 4 = 496字节） 。 二、 日志写入简要过程 1. mtr log生成 2. 从mtr_buf到logbuffer 拷贝mtr中的record unsigned long buf_free：buf中空闲的第一个位置，按照该位置向logbuffer中拷贝record。 max_buf_free：推荐的buf_free的最大值，会判断该值，如果超过max_buf_free，需要刷logbuffer；并设置log_sys->check_flush_or_checkpoint为true。 3. 从log buffer到logfile 日志的刷盘是通过调用void log_write_up_to( lsn_t lsn, bool flush_to_disk)，如果flush_to_disk为True，则表示将参数lsn之前日志都write&flush；同时更新相应偏移量。 三、 mtr  1. Mini transaction Mini transaction(简称mtr)是InnoDB对物理数据文件操作的最小事务单元，用于管理对Page加锁、修改、释放、以及日志提交到公共buffer等工作。 一个mtr操作必须是原子的，一个事务可以包含多个mtr。每个mtr完成后需要将本地产生的日志拷贝到公共缓冲区，将修改的脏页放到flush list上。 2. mtr_t结构 struct mtr_t {     /* mtr_t 内嵌一个结构体Impl. */     struct Impl {       mtr_buf_t m_memo;         /* 一个被加锁的对象以及它加的锁. */       mtr_buf_t m_log;          /* mini-transaction 的 log. */       bool m_made_dirty;        /* 是否修改了Buffer Pool中的Page为脏页. */       bool m_modifications;     /* 是否修改了Buffer Pool中的Page. */       ib_uint32_t m_n_log_recs; /* 该 mini-transaction 包含多少条log. */       mtr_log_t m_log_mode;     /* mini-transaction 的工作模式(MTR_LOG_ALL, MTR_LOG_NO_REDO,MTR_LOG_NONE).                                   Mtr的工作模式，包括四种：                                   MTR_LOG_ALL：默认模式，记录所有会修改磁盘数据的操作；                                  MTR_LOG_NONE：不记录redo，脏页也不放到flush list上；                                  MTR_LOG_NO_REDO：不记录redo，但脏页放到flush list上；                                  MTR_LOG_SHORT_INSERTS：插入记录操作REDO，在将记录从一个page拷贝到另外一个新建的page时用到，此时忽略写索引信息到redo log中。*/       mtr_state_t m_state;      /* mini-transaction 的状态: MTR_STATE_INIT, MTR_STATE_ACTIVE, MTR_STATE_COMMITTING, MTR_STATE_COMMITTED. */     } } 3. mtr_t中成员memo 是个latch持有状态的数组列表，采用的是dyn_array_t的动态内存结构来保存的，每个单元存储的是 mtr_memo_slot_t 。 m_memo中元素是mtr_memo_slot_t, 记录加锁的对象和加锁的类型. object是latch的对象，可以是rw_lock_t对象，也可以是buf_block_t对象。 /** mini-transaction memo stack slot. */ struct mtr_memo_slot_t {   void *object;  /* 加锁的对象. */   ulint type;    /* 持有的锁类型，W or R. */ }; 4. mt_t中的成员log 是也是一个dyn_array_t动态结构的内存，用来保存mtr产生的日志信息。日志的写入是通过mtr0log.h来写入的。 重做日志虽然有很多种类型，但重做的日志格式是统一的，日志格式是有日志头和日志体组成。 日志头信息是由type、space和page no组成，由mlog_write_initial_log_record_fast函数写入到mtr_t的log中的。 log body的数据写入是通过mtr0log.h中的日志写入方法进行写入的，每写入一条操作日志，n_log_recs会加1。 5. mini-transaction 具体流程 mtr_t mtr mtr.start() /* ... */ /* 写入数据至 mini-transaction 的 m_log. */ /* ... */ mtr.commit() (1). mini-transaction 的start() /** 启动一个 mini-transaction. */ @param synctrue if it is a synchronous mini-transaction @param read_onlytrue if read only mini-transaction */ void mtr_t::start(bool sync, bool read_only) {   UNIV_MEM_INVALID(this, sizeof(*this));   UNIV_MEM_INVALID(&m_impl, sizeof(m_impl));   m_sync = sync;   m_commit_lsn = 0;   new (&m_impl.m_log) mtr_buf_t();  /* 记录Redo log的mtr本地Buffer. */   new (&m_impl.m_memo) mtr_buf_t();   /* 初始化 mini-transaction 字段. */   m_impl.m_mtr = this;   m_impl.m_log_mode = MTR_LOG_ALL;   m_impl.m_inside_ibuf = false;   m_impl.m_modifications = false;   m_impl.m_made_dirty = false;   m_impl.m_n_log_recs = 0;   m_impl.m_state = MTR_STATE_ACTIVE;   m_impl.m_flush_observer = NULL;   ut_d(m_impl.m_magic_n = MTR_MAGIC_N); } (2). 锁的处理 不同的 mini-transaction 如何互斥? 在操作数据前，会根据锁类型，加不同类型的锁，之后将object和锁类型存入m_memo: mtr_memo_push(mtr, object, type); commit完成之后调用release_latches(RELEASE_ALL)将数据上的锁释放. (3). mini-transaction 插入数据 byte *mlog_open(mtr_t *mtr, ulint size): 打开mtr的m_log mlog_write_initial_log_record_low()函数向m_log中写入type，space id，page no，并增加m_n_log_recs的数量 mtr->get_log()->push()按不同的类型写数据 mlog_close(): 更新m_log中的位置 (4). mini-transaction 的 commit 过程 commit过程将mini-transaction的m_log数据拷贝到Redo Log Buffer中.  将m_state设置为MTR_STATE_COMMITTING后，调用mtr_t::Command::execute()。