首页 / MYSQL / MySQL之Innodb恢复的学习笔记

MySQL之Innodb恢复的学习笔记

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MySQL之Innodb恢复的学习笔记，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含14824字，纯文字阅读大概需要22分钟。

内容图文

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 (512*1 or 512*3)_
   读取如下：

                   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恢复的学习笔记全部内容，希望文章能够帮你解决MySQL之Innodb恢复的学习笔记所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/918740.html

来源：【匿名】

【上一篇】hive mysql元数据，报错 Specified key was too long; max key length is 767 bytes 【下一篇】用IE远程创建Mysql数据库的简易程序

更多 ►

【MySQL之Innodb恢复的学习笔记】教程文章相关的互联网学习教程文章

MySQL管理之 MyISAM和InnoDB存储引擎简单对比

版权归QQ87006009所有一、MyISAM引擎：1、隔离事务界别：由于myisam的隔离事务级别是串行。采用的是表级锁，不支持事物和全文索引。因此不适用在大并发，重负荷的生产系统上。 2、实例的崩溃恢复：当系统宕机或者mysql进程崩溃后，MyISAM引擎表很容易受到损坏。不得不用外部命令myisamchk来进行修复。 3、分配内存和使用：myisam引擎内存主要存放索引信息，不存放数据信息，因此在检索表时会先访问索引信息，然后在去磁盘读取数据信...

MySQL InnoDB锁问题【代码】【图】

InnoDB 与 MyISAM 的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。查看 InnoDB行锁争用情况show status like‘innodb_row_lock%‘; 如果发现锁争用比较严重，如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比较高，可以通过查询 information_schema 数据库中相关的表来查看锁情况，或者通过设置InnoDBMonitors来进一步观察发生锁冲突的表、数据行等，并分析锁争用的原因。（1）通过查询information...

mySql---剖析InnoDB索引原理【图】

摘要：本篇为参考别人的文章（http://blog.csdn.net/voidccc/article/details/40077329）1 各种树形结构本来不打算从二叉搜索树开始，因为网上已经有太多相关文章，但是考虑到清晰的图示对理解问题有很大帮助，也为了保证文章完整性，最后还是加上了这部分。先看看几种树形结构： 1 搜索二叉树：每个节点有两个子节点，数据量的增大必然导致高度的快速增加，显然这个不适合作为大量数据存储的基础结...

MySQL InnoDB表--BTree基本数据结构【图】

MySQL InnoDB表是索引组织表这一点应该是每一个学习MySQL的人都会首先学到的知识，这代表这表中的数据是按照主键顺序存储，也就是说BTree的叶子节点存储了所有该行的数据。我最开始是搞Oracle的，头一次接触MySQL的时候，默认引擎还是MyISAM。当时我看到公司建立的所有的InnoDB表都会在第一列加一个业务无关的自增主键，我觉得很没有必要，问了些人这么做的意义，得到的答案也是让人搞不懂，其实也都没有说到根本上，只是说这样...

MySQL InnoDB表的碎片量化和整理（data free能否用来衡量碎片？）【代码】【图】

网络上有很多MySQL表碎片整理的问题，大多数是通过demo一个表然后参考data free来进行碎片整理，这种方式对myisam引擎或者其他引擎可能有效（本人没有做详细的测试）.对Innodb引擎是不是准确的，或者data free是不是可以参考，还是值得商榷的。本文基于MySQL的Innodb存储引擎，数据库版本是8.0.18，对碎片（fragment）做一个简单的分析，来说明如何量化表的碎片化程度。涉及的参数1，information_schema_stats_expiryinformation_s...

MySQL InnoDB 快速导入数据【图】

今天把需要分析的数据导入到数据库中。　　数据将近7000万条，在txt文件中存放，共5.75G。采用Load data infile 导入，最后花了18个小时导入。主要做了以下修改：1. MySQL优化　　key_buffer_size = 64M　　max_allowed_packet = 8M　　innodb_buffer_pool_size = 1024M　　innodb_flush_log_at_trx_commit = 0　　innodb_support_xa = 02. MySQL设置戳我　（1）　　　SET autocommit=0; 　　　... SQL import statements 　　　.....

总是忘记的场景：MySQL InnoDB四个事务级别与脏读、不重复读、幻读

MySQL InnoDB事务隔离级别脏读、可重复读、幻读MySQL InnoDB事务的隔离级别有四级，默认是“可重复读”（REPEATABLE READ）。· 未提交读（READUNCOMMITTED）。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）。· 提交读（READCOMMITTED）。本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。· ...

MySQL 8 InnoDB 集群生产部署

生产部署InnoDB集群1、先决条件InnoDB集群使用组复制技术，所以InnoDB中的实例需要满足组复制要求。可以查看MySQL文档中组复制相关的部分，也可以通过AdminAPI提供的dba.checkInstanceConfiguration() 方法检查实例是否满足要求，如果不满足可以使用 dba.configureInstance() 方法配置实例以满足要求。组复制成员的表需要使用InnoDB存储引擎。如果表示用其他存储引擎，需要先转化为使用InnoDB存储引擎。Performance Schema需要开启...

MySQL InnoDB简介【图】

从MySQL 5.5版本开始InnoDB已经是默认的表存储引擎InnoDB1：完全支持ACID2：支持行级锁3：支持MVCC4：支持外键 MySQL 5.1版本MySQL 5.1版本之前，InnoDB被包含在MySQL的二进制发行版中，随着MySQL更新而更新5.1版本MySQL允许开发商以动态方式加载存储引擎，这样存储引擎的更新就不受MySQL版本的限制了。也就是说MySQL5.1版本可以支持2个InnoDB存储引擎1：静态编译的InnoDB2：动态加载的InnoDB 也称：InnoDB Plugin由于不支持多回滚...

MySQL Study之--MySQL innodb引擎备份工具XtraBackup之一（Install）【图】

MySQL Study之--MySQL innodb引擎备份工具XtraBackup之一（Install）Xtrabackup是一个对InnoDB做数据备份的工具，支持在线热备份（备份时不影响数据读写），是商业备份工具InnoDB Hotbackup的一个很好的替代品。　　Xtrabackup有两个主要的工具：xtrabackup、innobackupex　　（1）xtrabackup只能备份InnoDB和XtraDB两种数据表，而不能备份MyISAM数据表　　（2）innobackupex-1.5.1则封装了xtrabackup，是一个脚本封装，所以能同时...

mysql 备份软件 Xtrabackup 的 xtrabackup_binlog_pos_innodb和xtrabackup_binlog_info 文件区别【代码】

今天在操作 innobackupex 的时候，执行 change master to 的时候发现 xtrabackup_binlog_pos_innodb xtrabackup_binlog_info 两个文件对应的master 的 binary log 位置不一致： less xtrabackup_binlog_info mysql-bin.002961 70176740 less xtrabackup_binlog_pos_innodb mysql-bin.002961 38716155后面我就找了下这两个参数究竟是有什么区别 1.官网上的定义：xtrabackup_binlog_pos_innodb containing the position of the ...

Mysql的InnoDB引擎-5.索引（1）【图】

数据结构和算法二分查找法二分查找法也称为折半查找法。其基本思想是：将记录按照有序排列，在查找过程中采用跳跃式方式查找，即先以有序数列的中点进行大小对比，如果小于中心点元素，那么数据在中心点左侧，每次查询数据都将区间缩小一半，知道查询到对应数据。二叉查找树和平衡二叉树二叉树是一个经典的数据结构。具体如下图。二叉查找树具体如图，左子树的键值总是小于根的键值，右子树的键值总是大于根的键值。因此可以通过...

MySQL MyISAM和InNodb备份与恢复技巧【代码】

1. 为什么要备份数据库对数据库来说，最重要也最容易被忽视的就是备份。由于不可预测性，偶然的事件可能会导致非常惨重的损失。数据越是重要，数据的变化越频繁，备份越发需要经常进行。备份周期根据不同业务的需要可以调整，但是不能忽视备份。备份时最好也备份my.cnf或my.ini，这样可以保存你以前的配置参数。2. MyISAM 表备份/恢复策略2.1. 文件热备份2.1.1. 拷贝文件因为MySQL表保存为文件方式，很容易备份。要想保持备份的一致...

mysql 设置 innodb_print_all_deadlocks=ON, 保存死锁日志

Introduced5.6.2Command-Line Format--innodb-print-all-deadlocks=#System VariableNameinnodb_print_all_deadlocksScopeGlobalDynamicYesPermitted ValuesTypebooleanDefaultOFFWhen this option is enabled, information about all deadlocks in InnoDB user transactions is recorded in the mysqld error log. Otherwise, you see information about only the last deadlock, using the SHOW ENGINE INNODB STATUS command. ...

除Innodb和MyISAM外MySQL所支持的存储引擎【代码】【图】

MySQL常用存储引擎之CSV CSV存储引擎可以将CSV文件作为mysql表来处理，存储格式就是普通的CSV文件。如果把数据存储在myisam和Innodb中，存储数据的文件是不能直接查看的，因为这两种存储引擎都是以二进制文件存储的。而CSV是以文本方式存储的，CSV是不支持索引的，查找的时候要进行全表扫描。文件系统存储特点：数据以文本方式存储在文件中（Innodb则是二进制）.CSV文件存储表内容.CSM文件存储表的元数据如表状态和数据量.frm文件存...

MYSQL - 技术教程分类

MySQL 教程 MySQL 安装 MySQL 管理 MySQL PHP 语法 MySQL 连接 MySQL 创建数据库 MySQL 删除数据库 MySQL 选择数据库 MySQL 数据类型 MySQL 创建数据表 MySQL 删除数据表 MySQL 插入数据 MySQL 查询数据 MySQL WHERE 子句 MySQL UPDATE 更新 MySQL DELETE 语句 MySQL LIKE 子句 MySQL UNION MySQL 排序 MySQL 分组 MySQL 连接的使用 MySQL NULL 值处理 MySQL 事务 MySQL ALTER命令 MySQL 索引 MySQL 临时表 MySQL 复制表 MySQL 元数据 MySQL 序列使用 MySQL 处理重复数据 MySQL 及 SQL 注入 MySQL 导出数据 MySQL 导入数据 MySQL 函数 MySQL 运算符 mysql 全部

MYSQL - 最热教程

sql分组取最大记录方法 mysql如何设置默认值 mysql创建数据表时指定默认值教程 MySQL 5.7 的初始化操作（root初始密码...Oracle中合并数据集(多行变一行)mysql 相同内容的字段合并为一条的方法解决mysql设置时区时的错误Unknown or ...解决ubuntu下mysql的'Access denied fo...ubuntu系统中MysqlERROR1045(28000)报错...mysql数据库设置不区分大小写

首页 / MYSQL / MySQL之Innodb恢复的学习笔记

MySQL之Innodb恢复的学习笔记

内容导读

内容图文

内容总结

内容备注

内容手机端

【MySQL之Innodb恢复的学习笔记】教程文章相关的互联网学习教程文章

MySQL管理之 MyISAM和InnoDB存储引擎简单对比

MySQL InnoDB锁问题【代码】【图】

mySql---剖析InnoDB索引原理【图】

MySQL InnoDB表--BTree基本数据结构【图】

MySQL InnoDB表的碎片量化和整理（data free能否用来衡量碎片？）【代码】【图】

MySQL InnoDB 快速导入数据【图】

总是忘记的场景：MySQL InnoDB四个事务级别与脏读、不重复读、幻读

MySQL 8 InnoDB 集群生产部署

MySQL InnoDB简介【图】

MySQL Study之--MySQL innodb引擎备份工具XtraBackup之一（Install）【图】

mysql 备份软件 Xtrabackup 的 xtrabackup_binlog_pos_innodb和xtrabackup_binlog_info 文件区别【代码】

Mysql的InnoDB引擎-5.索引（1）【图】

MySQL MyISAM和InNodb备份与恢复技巧【代码】

mysql 设置 innodb_print_all_deadlocks=ON, 保存死锁日志

除Innodb和MyISAM外MySQL所支持的存储引擎【代码】【图】

MYSQL - 相关标签

MYSQL - 技术教程分类

MYSQL - 最新教程

MYSQL - 最热教程