结论:只要redo log和binlog保证持久化到磁盘,就能确保MySQL异常重启后,数据可以恢复。
binlog的写入机制
日志写入binlog cache,事务提交的时候,再把binlog cache写到binlog文件中。
每个线程都会被系统给binlog cache分配一片内存,参数binlog_cache_size用于控制单个线程内binlog cache所占内存的大小,超过之后就要暂存到磁盘
1 write操作指的是把日志写到文件系统的page cache,没有持久化到磁盘,所以比较快
2 fsync才将数据持久化到磁盘,这个才占磁盘IOPS
sync_binlog=0 的时候,表示每次事务都只write,不fsync
sync_binlog=1的时候,表示每次事务都会执行fsync
sync_binlog=N的时候,表示每次提交都write,但是N个事务之后才fsync
一般设置为100-1000中的值
redo log 的写入机制
redo log buffer中的并不是每次生成后都需要持久化到磁盘,但是由于自动执行的线程会刷一部分进到磁盘
innodb_flush_log_at_trx_commit设置值
1 为0的时候,每次事务提交,只是留在redo log buffer中
2 为1的时候,每次事务提交,直接持久化到磁盘
3 为2的时候 ,每次事务提交,直到page cache
innoDB 后台有一个线程,每隔1s 就会把redo log buffer中的日志,调用write写到文件系统的page cache,然后fsync持久化到磁盘
另外两种场景也会让redo log写入到磁盘中
1 一种是 redo log buffer到innodb_log_buffer_size一半的时候,后台线程会自动写盘。只是到page cache
2 并行的事务提交,顺带着把这个事务的redo log buffer持久化到磁盘