MySQL Innodb恢复的方法教程

62次阅读

共计 13589 个字符，预计需要花费 34 分钟才能阅读完成。

这篇文章主要介绍“MySQL Innodb 恢复的方法教程”，在日常操作中，相信很多人在 MySQL Innodb 恢复的方法教程问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”MySQL Innodb 恢复的方法教程”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！

MySQL · 引擎特性 · InnoDB 崩溃恢复过程

enum {
 SRV_FORCE_IGNORE_CORRUPT = 1, /*!  let the server run even if it
 detects a corrupt page */
 SRV_FORCE_NO_BACKGROUND = 2, /*!  prevent the main thread from
 running: if a crash would occur
 in purge, this prevents it */
 SRV_FORCE_NO_TRX_UNDO = 3, /*!  do not run trx rollback after
 recovery */
 SRV_FORCE_NO_IBUF_MERGE = 4, /*!  prevent also ibuf operations:
 if they would cause a crash, better
 not do them */
 SRV_FORCE_NO_UNDO_LOG_SCAN = 5, /*!  do not look at undo logs when
 starting the database: InnoDB will
 treat even incomplete transactions
 as committed */
 SRV_FORCE_NO_LOG_REDO = 6 /*!  do not do the log roll-forward
 in connection with recovery */};

innodb 中的 3 个 lsn

innodb 的 lsn 和 oracle 的 scn 一样，是一个重要的概念。比如

在 flush list 中正是是使用 low lsn 作为链表的条件
参考 buf_page_t 中的 lsn_t oldest_modification;

在 checkpoint 中记录的也是 lsn
参考宏

#define LOG_CHECKPOINT_NO 0#define LOG_CHECKPOINT_LSN 8#define LOG_CHECKPOINT_OFFSET 16#define LOG_CHECKPOINT_LOG_BUF_SIZE 24

在物理文件中每个块最后的刷新 lsn
参考宏 FIL_PAGE_LSN

在写日志落盘的时候也是以 lsn 为标准的
参考函数 log_write_up_to

实际上 lsn 就是表示的日志量的字节数，是一个累加的值，在 5.7 中表现为:

/* Type used for all log sequence number storage and arithmetics */typedef ib_uint64_t lsn_t;

及一个 8 字节非负的整数。最大值及 2 的 64 次方。有了这种物理上概念，lsn 很容易换算为当前日志的偏移量。

下面描述一下和检查点相关的几个 lsn

ibdata 第一个块 FIL 中的 lsn(flush lsn):ibdata 的 26 后面 8 字节是在 innodb 干净关闭的时候进行更新的，如果不正常关闭不会进行写入(FIL_PAGE_FILE_FLUSH_LSN)

redolog 中 MLOG_CHECKPOINT 的 lsn: redolog MLOG_CHECKPOINT lsn 的写入是在每次 checkpoint 的时候同步写入的. 干净关闭会更新。

redolog header 中的 lsn: 是在每次 checkpoint 的时候异步写入的在 MLOG_CHECKPOINT 写入之后. 干净关闭会更新。
我们表示为 lsn1/lsn2/lsn3
正常关闭 3 个 lsn 是相等的，如果非正常关闭 innodb,lsn1 不会更新，因此 lsn3 必然不和 lsn1 相等，则判定需要进行 carsh recovery。

if (checkpoint_lsn != flush_lsn) { ...... if (!recv_needed_recovery) { ib::info()    The log sequence number     flush_lsn
     in the system tablespace does not match 
   the log sequence number     checkpoint_lsn
     in the ib_logfiles!  // 出现这个警告说明需要恢复了，因为没有干净的关闭数据库，那么 flush_lsn 一定比 checkpoint_lsn 小
 if (srv_read_only_mode) { ib::error()    Can t initiate database 
   recovery, running in read-only-mode. 
 log_mutex_exit(); return(DB_READ_ONLY);
 }
 recv_init_crash_recovery(); // 初始化
 }
 }

MLOG_CHECKPOINT

log_checkpoint 函数由 master 线程调用，以及关闭数据库的时候调用，不断的向 redo log 中写入 MLOG_CHECKPOINT 和 MLOG_FILE_NAME

log_group_checkpoint 写入 checkpoint 信息到 log header

#0 mtr_t::commit_checkpoint (this=0x7fff761fb830, checkpoint_lsn=697558445) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/mtr/mtr0mtr.cc:592#1 0x0000000001ceb4b9 in fil_names_clear (lsn=697558445, do_write=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/fil/fil0fil.cc:7067#2 0x0000000001a521cc in log_checkpoint (sync=true, write_always=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1927#3 0x0000000001b856f2 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2596#4 0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744#5 0x0000003f74807aa1 in start_thread () from /lib64/libpthread.so.0#6 0x0000003f740e8bcd in clone () from /lib64/libc.so.6

正常 innodb 运行的情况下 checkpoint 是由 master 线程触发。我们知道脏数据通过 page clean 线程和 lru manager 线程是在不断写盘的，那么在进行异常重启的的时候我们必须要知道一个恢复的起点，但是这个起点是不能记录在内存中必要固化到磁盘，恢复的时候读取这个点以后的 redo 进行恢复，而 checkpoint 就是完成这个事情下面是 checkpoint 的执行流程。

正常情况下 master 会每秒进行检查点其作用有:(参考 log_checkpoint 函数)
1、检查是否有自上次检查点以来的脏数据写盘了
2、如果有则在 redo 里面会为每个修改过的文件写入 MLOG_FILE_NAME, 完成后写入一个总的 MLOG_CHECKPOINT(参考 fil_names_clear 函数)
MLOG_FILE_NAME 主要记录至上次检查点以来更改过的数据文件
MLOG_CHECKPOINT 主要记录检查点的 lsn
3、如果有则在 redo header 中写入相应的检查点信息包含(异步写)(参考 log_group_checkpoint 函数)

Log sequence number 697794162
Log flushed up to 697794162
Pages flushed up to 697794162
Last checkpoint at 697794153

697794162-697794153 = 9 刚好是 MLOG_CHECKPOINT 的长度
oldest_lsn = log_sys- last_checkpoint_lsn + SIZE_OF_MLOG_CHECKPOINT
SIZE_OF_MLOG_CHECKPOINT=9

redo 的写入有 6 个途径:
1、master 线程每秒调用栈帧(可能是 idle 可能是 active 和检测是否需要插入缓存合并有关)
2、master 线程每秒 checkpoint 调用 (可能是 idle 可能是 active 和检测是否需要插入缓存合并有关)
3、page clean 线程调用栈帧 /* Force the log to the disk before writing the modified block */
4、主线程 commit 调用栈帧
5、innodb shutdown
6、redo buffer 不足

1、master 线程调用栈帧(可能是 idle 可能是 active 和检测是否需要插入缓存合并有关)

#0 log_group_write_buf (group=0x33f29f8, buf=0x7fffa5b38000  \200\024 , len=512, pad_len=0, start_lsn=697764864, new_data_offset=166)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145#1 0x0000000001a50f95 in log_write_up_to (lsn=697765068, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493#2 0x0000000001a51163 in log_buffer_sync_in_background (flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1553#3 0x0000000001b84bd1 in srv_sync_log_buffer_in_background () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2312#4 0x0000000001b85666 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2586#5 0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744

2、master 线程 checkpoint 调用 (可能是 idle 可能是 active 和检测是否需要插入缓存合并有关)

#0 log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000  \200\024\002 , len=1024, pad_len=0, start_lsn=697789952, new_data_offset=139)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145#1 0x0000000001a50f95 in log_write_up_to (lsn=697790725, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493#2 0x0000000001a52247 in log_checkpoint (sync=true, write_always=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1934#3 0x0000000001b856f2 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2596#4 0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744

3、page clean 线程调用栈帧 /* Force the log to the disk before writing the modified block */

#0 log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000  \200\024\002 , len=13312, pad_len=1024, start_lsn=697778176, new_data_offset=468)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145#1 0x0000000001a50f95 in log_write_up_to (lsn=697790015, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493#2 0x0000000001c704c7 in buf_flush_write_block_low (bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1035#3 0x0000000001c70cea in buf_flush_page (buf_pool=0x33247d8, bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1237#4 0x0000000001c717f4 in buf_flush_try_neighbors (page_id=..., flush_type=BUF_FLUSH_LIST, n_flushed=0, n_to_flush=25)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1466#5 0x0000000001c71b57 in buf_flush_page_and_try_neighbors (bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, n_to_flush=25, count=0x7fffa02867c0)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1558#6 0x0000000001c72862 in buf_do_flush_list_batch (buf_pool=0x33247d8, min_n=25, lsn_limit=18446744073709551615)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1846#7 0x0000000001c72cb6 in buf_flush_batch (buf_pool=0x33247d8, flush_type=BUF_FLUSH_LIST, min_n=25, lsn_limit=18446744073709551615)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1926#8 0x0000000001c73104 in buf_flush_do_batch (buf_pool=0x33247d8, type=BUF_FLUSH_LIST, min_n=25, lsn_limit=18446744073709551615, n_processed=0x7fffa0286938)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:2071#9 0x0000000001c734ee in buf_flush_lists (min_n=25, lsn_limit=18446744073709551615, n_processed=0x7fffa02869c8)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:2202#10 0x0000000001c76a97 in buf_flush_page_cleaner_coordinator (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:3362

4、主线程 commit 调用栈帧

#0 log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000  \200\024\002 , len=2560, pad_len=0, start_lsn=697762816, new_data_offset=230)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145#1 0x0000000001a50f95 in log_write_up_to (lsn=697765030, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493#2 0x0000000001a51087 in log_buffer_flush_to_disk (sync=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1524#3 0x00000000019a9157 in innobase_flush_logs (hton=0x2e9fdd0, binlog_group_flush=true)
 at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4407#4 0x0000000000f65893 in flush_handlerton (thd=0x0, plugin=0x7ffff03588e8, arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2606#5 0x00000000015d7716 in plugin_foreach_with_mask (thd=0x0, func=0xf65835  flush_handlerton(THD*, plugin_ref, void*) , type=1, state_mask=4294967287, 
 arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:2318#6 0x0000000000f658ef in ha_flush_logs (db_type=0x0, binlog_group_flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2617#7 0x000000000185733d in MYSQL_BIN_LOG::process_flush_stage_queue (this=0x2e02c80, total_bytes_var=0x7ffff0358a88, rotate_var=0x7ffff0358a87, 
 out_queue_var=0x7ffff0358a78) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8541#8 0x000000000185899f in MYSQL_BIN_LOG::ordered_commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false, skip_commit=false)
 at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9189#9 0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440#10 0x0000000000f63df8 in ha_commit_trans (thd=0x7fff2c000b70, all=false, ignore_global_read_lock=false)

入口函数
innobase_start_or_create_for_mysql
recv_recovery_from_checkpoint_start
1、此函数需要输入 flush 的 lsn 及脏数据写入到的位置
这个数据从 FIL_PAGE_FILE_FLUSH_LSN 中读取，这个值
只在 ibdata 的第一个 page 有效其他均为 0, 他的读取来自于
函数 Datafile::validate_first_page，
其中
*flush_lsn = mach_read_from_8(
m_first_page + FIL_PAGE_FILE_FLUSH_LSN);

其写入由函数   正常 shutdown 才会写入, 非正常关闭不会写入，正常运行检查点也不会写入
fil_write_flushed_lsn  写入
mach_write_to_8(buf + FIL_PAGE_FILE_FLUSH_LSN, lsn);
栈帧

 #0 fil_write_flushed_lsn (lsn=696973727) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/fil/fil0fil.cc:1946
 #1 0x0000000001a538a7 in logs_empty_and_mark_files_at_shutdown () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:2464
 #2 0x0000000001b915a9 in innobase_shutdown_for_mysql () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0start.cc:2803
 #3 0x00000000019a8ffc in innobase_end (hton=0x2e9edd0, type=HA_PANIC_CLOSE) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4360
 #4 0x0000000000f62621 in ha_finalize_handlerton (plugin=0x3015cd0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:813
 #5 0x00000000015d3d25 in plugin_deinitialize (plugin=0x3015cd0, ref_check=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:995
 #6 0x00000000015d410e in reap_plugins () at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:1077
 #7 0x00000000015d6073 in plugin_shutdown () at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:1845
 #8 0x0000000000ebf7eb in clean_up (print_message=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/mysqld.cc:1336
 #9 0x0000000000ec701b in mysqld_main (argc=98, argv=0x2e9cf08) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/mysqld.cc:5386
 #10 0x0000000000ebd604 in main (argc=10, argv=0x7fffffffe458) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/main.cc:25

2、此函数首先建立红黑树用于恢复并且做 force recovery 判断
(srv_force_recovery = SRV_FORCE_NO_LOG_REDO)
然后调用
recv_find_max_checkpoint 此函数就是找到最大的 checkpoint lsn、redo 文件, 以及 field 就是相对于一个日志而讲所在的 offset set (5121 or 5123)_
读取如下：

 group- lsn = mach_read_from_8( buf + LOG_CHECKPOINT_LSN);
 group- lsn_offset = mach_read_from_8( buf + LOG_CHECKPOINT_OFFSET);
 checkpoint_no = mach_read_from_8( buf + LOG_CHECKPOINT_NO);

3、recv_group_scan_log_recs
循环读取 64K(RECV_SCAN_SIZE)日志到 redo buffer(log_group_read_log_seg)
recv_scan_log_recs
本函数将 64K 的 redo 通过每个 512 bytes block 大小循环加入到 (recv_sys_add_to_parsing_buf) 扫描到 parse buffer
代码片段拷贝

 ut_memcpy(recv_sys- buf + recv_sys- len,
 log_block + start_offset, end_offset - start_offset);
 
  当每次扫描了 64K*80 的日志量的时候会输出，级 5M
 ib::info()    Doing recovery: scanned up to 
   log sequence number     scanned_lsn;

  并且进行分析对这加入到  parse buffer 的日志进行分析(recv_parse_log_recs) / 其中 parse buffer  为 2M(宏 RECV_PARSING_BUF_SIZE 大小)
 recv_parse_log_recs 函数对每次加入  parse buffer 的 64k 进行分析主要分析是 MLOG_SINGLE_REC_FLAG 还是 MLOG_MULTI_REC_END  同时确认 MLOG_MULTI_REC_END
  是否完整，完成后加入到 hash table，函数是调用 recv_parse_log_rec 进行  (type spaceid page_no data)的剥离。

那么 recv_group_scan_log_recs 为第一层循环，循环扫描 64K 日志到 redo buffer
然后调用 recv_scan_log_recs 以 block 单位 (512b) 大小循环加入到 parse buffer，这是通过函数 recv_sys_add_to_parsing_buf 完成
等到 64k 加入到 parse buffer 后调用 recv_parse_log_recs 函数对每次加入 parse buffer 的 64k 进行分析，分析是循环以 record 为单位的，主要分析 MLOG_SINGLE_REC_FLAG 还是 MLOG_MULTI_REC_END，同时确保 MLOG_MULTI_REC_END 记录是完整的。完成后 recv_parse_log_recs 函数还要将其加入到 hash table 函数为 recv_add_to_hash_table，本函数是通过 recv_parse_log_rec 进行 (type spaceid page_no data)的剥离。

recv_apply_hashed_log_recs 最后完成分析完成后的日志应用，从 hash table 中

到此，关于“MySQL Innodb 恢复的方法教程”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！

正文完