这篇文章主要介绍InnoDB IO路径源码的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
InnoDB实现IO Flush通过“os_file_flush”宏收敛，macro展开后为”os_file_flush_func”。
接下来，我们重点看一下，还有其它哪些场景会调用到这个os_file_flush_func函数：
1. buf_dblwr_init_or_load_pages中，在double buffer 做crash恢复时，如果设置了reset_space_ids为”true”
2. fil_create_new_single_table_tablespace中，创建表数据文件时
3. fil_user_tablespace_restore_page中，从double writer buffer中copy page时
4. fil_tablespace_iterate中，如果iterate page失败时，会做一次sync
5. os_file_set_size中，在文件新创建时初始化文件大小时
从上面可以看出，直接调用os_file_flush_func还是非常少的。那么系统中还有一些是调用os_file_flush_func的上层函数fil_flush：
1. buf_dblwr_flush_buffered_writes中，flush double write buffer到disk
2. buf_dblwr_write_single_page中，单页flush到disk中
3. buf_flush_write_block_low中，flush block到disk中，一般在调double write buffer“buf_dblwr_flush_buffered_writes“之后调用
4. buf_LRU_remove_pages中，delete某个tablespace中的page时，做sync调用
5. fil_rename_tablespace中，rename一个tablespace时调用
6. fil_extend_space_to_desired_size中，extend space时
7. fil_flush_file_spaces中，flush 批量tablespace的page时，被ha_innodb的force checkpoint时调用，shutdown DB时调用等
8. log_io_complete中，log io完成时，checkpoint write以及其它，是否调用受sync方式影响，非commit依赖
9. log_write_up_to中，commit事务时，这个是重点，innodb 的log file都会调用，而且是同步
10. create_log_files_rename中，rename log file时
11. innobase_start_or_create_for_mysql中，创建新的文件时
在fil_flush函数中，所有文件的flush cache行为受fil_system->mutex保护。因此不管是data file还是log file，文件级别的flush是串化的。那么具体是怎么来控制的呢？
1. 检查file node中的n_pending_flushes，如果大于“0”就一直retry
2. 如果为“0”，进入flush阶段，在正式开始flush之前，先将n_pending_flushe加“1”，这个操作受上文提到的“fil->mutex“保护
3. 调用“os_file_flush“ flush完成之后，n_pending_flushes减“1”，也同样由“fil->mutex“保护
下面是MySQL中retry的代码：
retry: if (node->n_pending_flushes > 0) { /* We want to avoid calling os_file_flush() on the file twice at the same time, because we do not know what bugs OS's may contain in file i/o */ ib_int64_t sig_count = os_event_reset(node->sync_event); mutex_exit(&fil_system->mutex); os_event_wait_low(node->sync_event, sig_count); mutex_enter(&fil_system->mutex); if (node->flush_counter >= old_mod_counter) { goto skip_flush; } goto retry; } |
下面是MySQL中flush的代码：
ut_a(node->open); file = node->handle; node->n_pending_flushes++; mutex_exit(&fil_system->mutex); os_file_flush(file); mutex_enter(&fil_system->mutex); os_event_set(node->sync_event); node->n_pending_flushes--; node->flush_size = node->size; |
上面提到的逻辑，对于log file也同样处理。Log file的tablespace为log space。对于log file，还受到log_sys->mutex的保护，在log_write_up_to函数中。
Log file的flush行为收敛到“log_write_up_to”函数体中，再调用fil_flush，最终走到os_file_flush_func。
MySQL在commit的时候，如果”innodb_flush_log_at_trx_commit=1”时，调用两次同步的log_write_up_to，一次是innobase log file 的flush，一次是bin log的flush。
如果关掉bin log，则在ordered_commit函数中，不会走sync_blog分支。以下是关掉和不关掉时，innobase flush log file的执行路径。
不带binlog时的Innobase 的pstack如下：
fsync,os_file_fsync,os_file_flush_func,fil_flush,log_write_up_to,trx_flush_log_if_needed_low,trx_flush_log_if_needed,trx_commit_complete_for_mysql,innobase_commit,ha_commit_low,TC_LOG_DUMMY::commit,ha_commit_trans,trans_commit_stmt,mysql_execute_command,mysql_parse,dispatch_command,do_command,do_handle_one_connection,handle_one_connection,start_thread,clone |
带Binlog的flush pstack如下：
fsync,os_file_fsync,os_file_flush_func,fil_flush,log_write_up_to,innobase_flush_logs,flush_handlerton,plugin_foreach_with_mask,ha_flush_logs,MYSQL_BIN_LOG::process_flush_stage_queue,MYSQL_BIN_LOG::ordered_commit,MYSQL_BIN_LOG::commit,ha_commit_trans,trans_commit_stmt,mysql_execute_command,mysql_parse,dispatch_command,do_command,do_handle_one_connection,handle_one_connection,start_thread,clone |
从上面大致的调用来看，log_write_up_to()和log_io_complete()将是重点，因为这些flush在file级别是串行的，commit时的rt主要由这些串化带来。
接下来我们看一下log_write_up_to的调用者都有那些：
1. buf_flush_write_block_low，在force flush中调用，保证日志必须先于数据落地，刷脏页时，由page_cleaner_do_flush_batch()发起调用到此函数
2. innobase_flush_logs，在commit时调用，主要由flush binlog分支调用
3. trx_flush_log_if_needed_low，在commit时调用，主要由flush innodb log file时调用
4. log_buffer_flush_to_disk，log buffer刷日志到disk
5. log_buffer_sync_in_background，后台线程同步log buffer到disk，由srv_master_thread 线程调srv_sync_log_buffer_in_background()调用到，每秒一次
6. log_flush_margin，主要为腾挪log buffer空间时调用
7. log_checkpoint，主要在做checkpoint时调用到，由srv_master线程调用srv_master_do_idle_tasks()，每秒做一次
log_io_complete()函数的调用情况：
1. fil_aio_wait，aio wait中如果是log io将会调用此方法
从上面分析可以看到，主要影响RT比较严重的还是因为刷脏页导致的log_sys->mutex争用。另外，log_buffer_sync_in_background和log_checkpoint，这两个都是由后台srv_master_thread线程每隔一秒调用到。
但是这两个方法不一定会执行fil_flush，所以不是影响的主因。gdb挂上去后，大致会走到fil_flush争用的pstack如下：
因此，总结起来，应该是commit做的两次fsync加上一次page cleaner做的log_write_up_to()。另外，还有一个fil_aio_wait完成时，如果是log io，就会做一次log_io_complete()。
这四次fsync都会对用户的rt有影响，commit的两次无可避免，后面两次最多也就是调整频率。另外是否可以改变fsync的方式？这个读者可以思考。
比oracle实现差，oracle不会作强制的，我记得是给一个标记，策略还是按redo自己的策略来做。oracle的实现应该是考虑到这一点了.
以上是“InnoDB IO路径源码的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
