深入解析MySQL检查点.ppt

,深入解析Mysql检查点,搜狐畅游 DBA 王洪权 2011-07-06,summarry,Mysql log file Mysql 检查点 Mysql doublewrite,基本操作,基本操作,基本操作,基本操作,基本操作,基本操作,基本操作,基本操作,.,为什么要采取异步刷新,Why ?,为什么要采取异步刷新,1 This is an optimization 2 It call it write combining,关于log工作原理,/index.php/2009/08/innodb-dirty-page-redo-log-2/,innodb_flush_log_at_trx_commit,Log buffer设置建议,mysqladmin var|grep log_buffer innodb_log_buffer_size | 8388608 通常设置范围816M 通常8M 比较合适，除非有很多blob/text字段操作，或大事务操作。,Log buffer设置,show global status like %Innodb_log_waits%; +-+-+ | Variable_name | Value | +-+-+ | Innodb_log_waits | 0 | +-+-+ Innodb_log_waits The number of times that the log buffer was too small and a wait was required for it to be flushed before continuing.,innodb_log_file_size,关于innodb_log_file_size大小设置 如何找到最佳的均衡点呢？ /2006/07/03/choosing-proper-innodb_log_file_size/ /2008/11/21/how-to-calculate-a-good-innodb-log-file-size/,innodb_log_file_size,innodb_log_file_size设置,大概7M每分钟，那么一个小时是多少呢，7*60=420M,所以单个logfile大小256M大小足够。 2008 By Baron Schwartz /2008/11/21/how-to-calculate-a-good-innodb-log-file-size/,innodb_log_file_size设置,修改innodb_log_file_size,1 干净的关闭数据库，删除日志文件，修改f 中innodb_log_file_size，重启mysql 2 干净的关闭数据库，rename日志文件，修改f 中innodb_log_file_size，重启mysql,Log写入 LSN实际上对应日志文件的偏移量，新的LSN旧的LSN + 写入的日志大小。举例如下： LSN1G，日志文件大小总共为600M，本次写入512字节，则实际写入操作为： l 求出偏移量：由于LSN数值远大于日志文件大小，因此通过取余方式，得到偏移量为400M； 写入日志：找到偏移400M的位置，写入512字节日志内容，下一个事务的LSN就是1000000512；,Innodb日志机制深入分析,Innodb日志机制深入分析,Checkpoint写入,Innodb实现了Fuzzy Checkpoint的机制，每次取到最老的脏页，然后确保此脏页对应的LSN之前的LSN都已经写入日志文件，再将此脏页的LSN作为Checkpoint点记录到日志文件， 意思就是“此LSN之前的LSN对应的日志和数据都已经写入磁盘文件”。恢复数据文件的时候，Innodb扫描日志文件，当发现LSN小于Checkpoint对应的LSN，就认为恢复已经完成。 Checkpoint写入的位置在日志文件开头固定的偏移量处，即每次写Checkpoint都覆盖之前的Checkpoint信息。,Innodb日志机制深入分析,管理机制,Checkpoint和日志紧密相关，将日志和Checkpoint一起说明，详细的实现机制如下：,Innodb日志机制深入分析,如上图所示，Innodb的一条事务日志共经历4个阶段： 创建阶段：事务创建一条日志； 日志刷盘：日志写入到磁盘上的日志文件； 数据刷盘：日志对应的脏页数据写入到磁盘上的数据文件； 写CKP：日志被当作Checkpoint写入日志文件；,Innodb日志机制深入分析,对应这4个阶段，系统记录了4个日志相关的信息，用于其它各种处理使用： Log sequence number（LSN1）：当前系统LSN最大值，新的事务日志LSN将在此基础上生成（LSN1+新日志的大小）； Log flushed up to（LSN2）：当前已经写入日志文件的LSN； Oldest modified data log（LSN3）：当前最旧的脏页数据对应的LSN，写Checkpoint的时候直接将此LSN写入到日志文件； Last checkpoint at（LSN4）：当前已经写入Checkpoint的LSN； 对于系统来说，以上4个LSN是递减的，即： LSN1=LSN2=LSN3=LSN4.,Innodb日志机制深入分析,Innodb日志机制深入分析,Innodb日志机制深入分析,Innodb的数据并不是实时写盘的，为了避免宕机时数据丢失，保证数据的ACID属性，Innodb至少要保证数据对应的日志不能丢失。对于不同的情况，Innodb采取不同的对策： 宕机导致日志丢失 Innodb有日志刷盘机制，可以通过innodb_flush_log_at_trx_commit参数进行控制； 日志覆盖导致日志丢失 Innodb日志文件大小是固定的，写入的时候通过取余来计算偏移量，这样存在两个LSN写入到同一位置的可能，后面写的把前面写得就覆盖了，以“写入机制”章节的样例为例，LSN100000000和LSN1600000000两个日志的偏移量是相同的了。这种情况下，为了保证数据一致性，必须要求LSN=1000000000对应的脏页数据都已经刷到磁盘中，也就是要求Last checkpoint对应的LSN一定要大于1000000000，否则覆盖后日志也没有了，数据也没有刷盘，一旦宕机，数据就丢失了。,1 Sharp 检查点。 2 Fuzzy checkpoint,Mysql 检查点的类型,通常这里的sharp指的是刷新BP中所有的脏页到datafile中。 脏页刷新完毕的时候产生一个sharp checkpoint 例如关闭数据库的时候发生sharp检查点 大概步骤是 1停止所有的更新操作 2 刷新所有的脏页到磁盘 3 写入当前的检查点信息到日志文件 4 把检查点信息写入到每个datafile中。,Sharp checkpoint介绍,1 受参数innodb_max_dirty_pages_pct 影响 2 percona 中引入innodb_adaptive_flushing_method 3 根据日志大小进行适时的刷新,Fuzzy checkpoint,每1S 若buffer pool中的脏页比率超过了srv_max_buf_pool_modified_pct = 75，则进行Checkpoint，刷脏页，flush PCT_IO(100)的dirty pages= 200 若采用adaptive flushing，则计算flush rate，进行必要的flush flush PCT_IO(100)的dirty pages= 200 每10S 若buffer pool中的脏页比率超过了70%，flush PCT_IO(100)的dirty pages dirty pages= 200 若buffer pool中的脏页比率未超过70%，flush PCT_IO(10)的dirty pages= 20,Checkpoint触发条件,深入理解内存中的数据结构,内存结构中buffer pool中的数据结构 Free list LRU list Flush list,和检查点相关的数据结构,1.LRu list 2.Flush list,关于LRU,Specifies the approximate percentage of the InnoDB buffer pool used for the old block sublist. The range of values is 5 to 95. The default value is 37 (that is, 3/8 of the pool).,关于FLUSh list,实际上就是所有的脏页的一个先后的修改顺序排列,Get total buffer pool statistics. */ buf_get_total_list_len( for (i = 0; i LRU); *free_len += UT_LIST_GET_LEN(buf_pool-free); *flush_list_len += UT_LIST_GET_LEN(buf_pool-flush_list); ,innodb_max_dirty_pages_pct 在数据库源代码中的体现,buf0buf.c,buf_get_modified_ratio_pct(void) ulint ratio; ulint lru_len = 0; ulint free_len = 0; ulint flush_list_len = 0; buf_get_total_list_len( ,innodb_max_dirty_pages_pct 在数据库源代码中的体现,buf0buf.c,反映在数据库上的脏页比率,脏页的比率计算,可以看出数据库典型,反映在数据库上的脏页比率,相关性能参数在数据库上的反映,Checkpoint触发,Checkpoint触发,计算过去一段时间内，flush的平均速度；与当前需要的flush速度 其中，BUF_FLUSH_STAT_N_INTERVAL = 20S不变，计算的仍旧是过去20S内的平均flush速度 若当前所需速度 20S内的平均速度，则adaptive flushing会尝试进行一次flush操作。flush的dirty pages数量仍旧是PCT_IO(100)，200个dirty pages。,Checkpoint触发检查点,函数流程： buf0buf.cbuf_flush_get_desired_flush_rate 1. 从buf_pool_t结构中，获得总dirty page的数量 2. 计算最近一段时间之内，redo日志产生的平均速度 其中，BUF_FLUSH_STAT_N_INTERVAL = 20S，20S内的平均redo产生速度 /* Number of intervals for which we keep the history of these stats. Each interval is 1 second, defined by the rate at which srv_error_monitor_thread() calls buf_flush_stat_update(). */ #define BUF_FLUSH_STAT_N_INTERVAL 20 flush的统计信息，每隔20S会被buf_flush_stat_update函数重置,Checkpoint触发检查点,刷新脏页到磁盘的算法,首先计算可选的neighbors flush脏页之前，必须保证脏页对应的日志已经写回日志文件 将数据拷贝到double writememory 将double writememory写出到disk doublewrite buffer的写，为同步写，调用 在doublewrite buffer被成功flush到disk之后，对应的dirty pages不会再丢失数据。此时再将doublewrite buffer对应的dirty pages写出到disk 标识当前flush操作结束(buf_flush_end) 收集当前flush操作的统计信息 更新检查点信息,检查点更新流程,流程一 每10秒更新检查点 流程二 在高IO系统中每1秒更新检查点,Innodb日志机制深入分析,为了解决第二种情况导致数据丢失的问题，Innodb实现了一套日志保护机制，详细实现如下：,为了解决第二种情况导致数据丢失的问题，Innodb实现了一套日志保护机制，详细实现如下：,“sync” point is at about 7/8 of innodb_log_file_size, and the “async” point is at about 6/8 = 3/4 of innodb_log_file_size.,Innodb日志机制深入分析,Innodb日志机制深入分析,Innodb日志机制深入分析,检查点的一些总结,mysql检查点事件受两个因