MySQL——innodb日志管理

innodb日志管理机制：

1、innodb存储引擎是支持事务ACID特性的，这个理论基本就是一个关系型数据库相关的数据恢复原形设计，包括日志、回滚、redo、并发控制、buffer pool等管理方面，内容非常全面；

2、innodb的buffer pool主要用来存储访问过的数据页面，他就是一块连续的内存，通过一定的算法可以使这块内存得到有效的管理，它是数据库系统中拥有最大块内存的系统模块。

   innodb存储引擎中数据的访问是按照页（也可以叫块，默认为16KB）的方式从数据库文件读取到buffer pool中的，然后在内存中用同样大小的内存空间来做一个映射；未来提高数据访问效率，数据库系统预先就分配了很多这样的空间，用来与文件中的数据进行交换；buffer pool的大小可以在配置文件中配置，有参数innodb_buffer_pool_size的大小来决定，默认大小为128MB。在MySQL5.7.4以前，一旦MySQL启动这个值便不能再做修改，如果要修改只能退出MySQL进程，然后修改对应的配置文件来设置新的buffer pool大小，重启才能生效。

注意：在MySQL5.7.5之后，可以在MySQL进程运行的情况下，动态调整innodb_buffer_pool_size，需要强调的是，如果buffer pool的大小超过了1GB，应该通过调整innodb_buffer_pool_instances=N，把它分成若干个instance的做法，来提示MySQL处理请求的并发能力，因为buffer pool是通过链表的方式来管理页面的，同时为了保护页面，需要在存取的时候对链表加锁，在多线程的情况下，并发去读写buffer pool里面缓存的页面需要锁的竞争和等待。所以修改为多个instance，每个instance各自管理自己的内存和链表，可以提升效率。

3、buffer pool实现原理：

   buffer pool可以有多个实例，可以通过配置文件中的参数innodb_buffer_pool_instance来设置，默认值为1，实现多个实例的buffer pool主要是为了提高数据页访问时的并发度。每个实例的空间大小都是相同的，也就是说系统会将整个配置的buffer pool大小按实例个数平分，然后每个实例各自进行初始化操作；

--注意：在运维过程中，看到状态参数innodb_buffer_pool_bytes_data总是比innodb_buffer_pool_size小，就是因为控制头信息占用了部分空间。实际的分配方式是，buffer pool页面从整个实例池中从后向前分配，每次分配一个页面，而控制结构使从前向后分配，每次分配一个buf_block_t结构的大小，知道相遇为止，这样就将一个实例初始化好了。

第一、redo log日志文件管理：

   redo log是用来做数据库crash recovery的，这是数据库保障数据安全的重要功能之一。在数据库操作中，它保存了对innodb表中数据的修改记录，所以也叫日志文件。在innodb存储引擎中，一般默认包括2个日志文件，新建数据库之后会有名为ib_logfile0 和ib_logfile1的两个文件，如果在启动数据库时，这两个文件不存在，则innodb会根据配置参数或默认值，重新创建日志文件；

1.1、LSN 全名叫：log sequence number：

  在innodb内部的日志管理中，一个很重要的概念是LSN，全名叫log sequence number，它用来精确记录日志位置信息，且是连续增长的。在innodb中，大小为8个字节值，它的增长量是根据一个MTR写入的日志量来计算的，写多少日志，LSN就增长多少。（LSN是一个完全逻辑的概念，每提交一个物理事务，LSN就加1）

1.2、在innodb中，通过日志组来管理日志文件，是一个逻辑定义，包含若干个日志文件，一个组中的日志文件大小相等，大小通过参数来设置，现在innodb只持有一个日志组。（在MySQL5.5以前日志组最大4G；MySQL5.6.3以后可以设置的更大到512G）

1.3、redo日志的写入，都是字节连续的，虽然看上去是多个日志文件，但理解的时候，完全可以把它想象成一个文件。（日志组中的每个日志文件，都有自己的格式，内部也是按照大小相等的页面切割，每个页面大小是512字节）

---注意：如果每次写入是磁盘块大小的倍数，效率才是最高的，并且日志将逻辑事务对数据库的分散随机写入转化成了顺序的512字节整数倍数据的写入，这样就大大提高了数据库的效率。

1.4、redo日志文件的格式：

  每个日志文件，都有文件头（普通页面中，都会有12个字节用来存储页面头信息，这些信息主要用于管理这个页面本身的数据存储方式；---注意只有2KB是日志头，后面是一个个连续的，用来存储MTR产生的日志页面）

1.5、MTRinnodb物理事务：

   它是innodb存储引擎中一个很重要的用来保证物理页面写入操作完整性及持久性的机制。之所以被称为MTR，是因为它的意义相当于一个mini-transaction，用MTR来表示，这里吧它称作“物理事务”，这样叫是相对逻辑事务而言的。

物理事务既然被称为事务，那它同样有事务的开始和提交，物理事务的开始其实就是对物理事务结构体mtr_struct的初始化，物理事务的提交主要是将所有这个物理事务产生的日志写入到innodb日志系统的日志缓冲区中，然后等待srv_master_thread线程定时将日志系统的日志缓冲区的日志数据刷到日志文件中；

---注意：日志缓冲区的存储只是一个暂时的中间状态，日志缓冲区的大小可以通过参数innodb_log_buffer_size来设置，一般都比较小，存储不了多少日志。

--日志是在逻辑事务对数据库做DML操作时，其所包含的物理事务MTR所记录的，针对所有涉及的buffer pool页面的修改记录；

1.6、日志提高性能的关键原因：

①：因为日志是用来记录buffer pool中page的修改记录的，所以把page的写入转化为对日志的写入，那此时page就不需要每次都刷盘，写page页面只需要在内存中写入即可，性能会非常好；

②：通常，一个页面是16KB，如果不写入职，每次写入的单位还是16KB，即使修改很少的数据，也是如此，这样会导致无效IO非常严重。

1.7、redo日志大小设置的问题：

①：如果设置的非常大，固然性能可能会很好，但是如果数据库出现异常停机，此时可能有很多日志都没有刷盘，也就是log flushed up to 与 last          checkpointat 两个值之间相差太多，恢复需要比较长的时间。（redo日志的恢复是顺序的，都是根据页面号的大小排序恢复的；）

②：日志容量大小的设置，最好与buffer pool的总大小匹配。如果日志容量太小，buffer pool太大，这就会导致buffer pool频繁做检查点，大的buffer      pool不能被好好利用，如果日志容量过大，而buffer pool很小，此时buffer page经常会被淘汰出去，增加IO频次，同时如果数据库意外宕机，buffer     pool太小，恢复起来也会比较慢；

1.8、redo日志记录格式：

 innodb的日志是具有逻辑意义的物理日志，所以，日志记录的格式就不完全是物理信息，而是有一定逻辑意义，基本的格式如下：
type(日志类型)，space（表空间ID值），offset（前面space所指定的文件中的页面号，以页面大小为单位），data（表示这条日志记录对应的数据，这个数据是不确定的，根据不同的type值而不同）
---type类型有很多，比较常用的有：
①：mlog_ibyte、mlog_2bytes、mlog_4bytes、mlog_8bytes：这四个类型，表示要在某个位置，写入一个（两个、四个、八个）字节的内容；
②：mlog_write_string：这种类型的日志，其实和mlog_ibyte是类似的，只是mlog_ibyte是要写一个固定长度的数据，而mlog_write_string是要写一段变长的数据。
③：mlog_undo_insert：这个类型的日志，是在将一条记录设置为页面中的最小记录时产生的，因为只是打个标记，存储的内容比较简单；
④：mlog_init_file_page：这个类型的日志比较简单，只有前面的基本头信息，没有data部分；
⑤：mlog_comp_page_create：这个类型只需要村一个类型及要创建的页面的位置即可；
⑥：mlog_multi_rec_end：这个类型的记录是非常特殊的，它只起一个标记的作用，其存储的内容只有占一个字节的类型值。
⑦：mlog_comp_rec_clust_delete_mark：这个类型的日志是表示，需要将聚集索引中的某个记录打上删除标志；
⑧：mlog_comp_rec_update_in_place：这个类型的日志记录更新后的记录信息，包括所有被更新的列的信息。
⑨：mlog_comp_page_reorganize：这个类型的日志表示的是要重组指定的页面，其记录的内容也很简单，只需要存储要重组哪一个页面即可；

1.9、日志刷盘时机：共有5种时机：

①：log buffer空间用完了，这就会将已经产生的log buffer中的日志刷到磁盘中，这是最普遍的一种方式；
②：master线程在后台每秒钟刷一次，将当前log buffer中的日志刷到磁盘中；
③：每次执行DML操作时，都会主动检查日志空间是否足够，如果使用空间的量已经超过了一个预设的经验值，就会主动刷日志，以保证在后面真正执行时，不会再执行过程中被动的刷盘，但这里只会是写文件（写入OS缓冲中）不会刷盘
④：在做检查点的时候，要保证所有要刷的页面中LSN值最小的日志已经刷入到磁盘，不然，如果此时数据库宕机，日志不存在，但数据页面已经被修改，从而导致数据不一致，就违背了写日志的原则；
⑤：提交逻辑事务时，会因为参数innodb_flush_log_at_trx_commit值的不同，产生不同的行为。如果设置0，则在事务提交时，根本不会去刷日志缓冲区，这种设置是最危险的；如果设置2，则在事务提交时会将日志写入到文件中，但不会去刷盘，只要操作系统不挂，即使数据库挂了，数据还是不会丢失，一般都是设置为2；

1.10、redo log刷盘机制：

当提交事务（逻辑）时，可以通过参数innodb_flush_log_at_trx_commit来控制redo log写入的机制，参数值不同，产生的行为不同，主要参数值如下：

①：innodb_flush_log_at_trx_commit=0
  事务提交时，MySQL不会去处理日志缓存区的内容，也不会去处理日志文件的刷盘操作，由MySQL的后台master线程每隔1s将缓存区的文件刷新到日志文件中；（主机正常，数据库宕机后：一般只会丢失最近1s的事务）
②：innodb_flush_log_at_trx_commit=1
  事务提交时，会将日志缓冲区的日志写入到文件中，同时会刷新到磁盘中，保证数据库事务完全不会丢失。这种设置影响数据库性能；（主机正常，数据库宕机后：数据不会丢失）
③：innodb_flush_log_at_trx_commit=2
  事务提交时，会将日志缓存区日志写入到文件中，但是不会刷新到磁盘中。由MySQL的后台master线程每隔1s将系统缓存的日志文件刷新到磁盘中；（主机正常，数据库宕机后：数据不会丢失）

---注意：如果数据库所在主机宕机后：参数0 会丢失最近1s的事务；参数1 不会有任何数据丢失； 参数2 会丢失最近1s的事务；

第二、数据库undo段管理：

在innodb中支持的回滚段总共有：128X1024=131072个，在每一个事务开始的时候，都会分配一个rseg，就是从长度为128的数组中，根据最近使用的情况，找到一个临近位置的rseg；

在事务执行的过程中，会产生两种回滚日志，一种是insert的undo记录，一种是update的undo记录；（因为innodb把undo分为两类，一类就是新增，也就是insert，一类是修改，就是update，分类的依据就是事务提交后要不要做purge操作，因为insert是不需要purge的，只要事务提交了，那这个回滚记录就可以丢掉了，而对于更新和删除操作而言，如果事务提交了，还需要为MVCC服务，那就需要将这些日志放到history list中去，等待去做purge已经MVCC的多版本查询等，所以分为两类）

2.1、数据库undo日志记录格式：

 undo有4种类型：

①：trx_undo_insert_rec：记录插入的undo日志类型，插入记录用于回滚时，只需要通过其主键就可以实现回滚操作，所以在undo日志中，只记录了表ID及主键信息；
②：trx_undo_upd_exist_rec：更新一条存在记录的undo日志类型；
③：trx_undo_upd_del_rec：更新一条已经打了删除标志记录的undo日志类型；
④：trx_undo_del_mark_rec：删除记录时对记录打删除标志的undo日志类型；
---注意：与redo日志记录存储不同，undo日志的存储，是不会垮页面的；
---注意：使用参数innodb_force_recovery来决定要不要做回滚操作，如果设置3或3以上，那么在启动innodb的时候就不回滚了，这样可能导致数据库逻辑上的不一致；