关于mysql的redo日志参数innodb_log_write_ahead_size中read-on-write的理解
先来说说innodb_log_write_ahead_size, 这个参数是在5.7.4引入的.
#innodb_log_write_ahead_size 默认为8192.
#引入write-ahead,将当前写入redo文件的偏移量整除innodb_log_write_ahead_size该值,不能整除时则补0,多写一部分数据,这样一来,写入的数据是与磁盘的block size保持一致了.这样就可以直接写入磁盘.就省去了先读到系统内存,再修改大小,再写入的过程....
在引入innodb_log_write_ahead_size之前,redo的刷盘是采用read-on-write模式的,关于read-on-write的理解如下:
首先看官方说法:
Read-on-write occurs when redo log blocks are not entirely cached to the operating system or file system due to a mismatch between write-ahead block size for redo logs and operating system or file system cache block size.
我大概理解了下read-on-write: innodb是以512字节一个block写入redo文件的,一般的linux的文件系统都是4k大小的..如果需要写入的日志文件块不在操作系统的cache时,就需要将对应的4k大小的block读入系统内存,修改512字节,然后在写入磁盘... 看淘宝的解析.是这么个意思...
引入write-ahead,将当前写入redo文件的偏移量整除innodb_log_write_ahead_size该值,不能整除时则补0,多写一部分数据,这样一来,写入的数据是与磁盘的block size保持一致了.这样就可以直接写入磁盘.就省去了先读到系统内存,再修改大小,再写入的过程....
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/20892230/viewspace-2127476/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
最新文章
- MySQL在线加索引引起的堵塞案例引出Online DDL锁分析
- 结合案例说说5.7使用gtid同步后,mysql.gtid_executed引起的从库gtid断层
- mysqldump一个小功能描述:参数net-buffer-length的使用
- 通过一个案例分析binlog的刷盘过程:大事物提交导致整库事物堵塞的分析.
- mysql对于unique_checks的支持
- 通过一个案例分析讲解mysql的auto_increment锁带来的表锁(innodb_autoinc_lock_mode)
- 基于GTID的一主两从,主从切换案例分析(Got fatal error 1236 )
- 案例分析:mysql子查询,DEPENDENT SUBQUERY特别小心
- binlog很有用的2个参数binlog_rows_query_log_events和binlog_row_image
- crash-safe replication的解析及主从注意事项
