目录
日志文件
binlog
binlog指二进制日志,它记录了数据库上的所有改变,并以二进制的形式保存在磁盘中,它可以用来查看数据库的变更历史、数据库增量备份和恢复、MySQL的复制(主从数据库的复制)。
binlog有三种格式:
statement:基于SQL语句的复制(statement-based replication,SBR)
row:基于行的复制(row-based replication,RBR)
mixed:混合模式复制(mixed-based replication,MBR)
redolog
1. 用途
保证数据的更新操作不丢失,同时保证了性能
2. 如何使用redo log来保证更新操作的不丢失?
数据修改成功之后,就需要将该数据页刷到磁盘中去,以防丢失,但是现在已经引入了redo log,此时只需要这个修改信息写入到redo log当中,也就是将哪个数据页哪里发生了修改写入到redo log当中,而不需要将修改过的整个数据页刷到磁盘当中去
3. 写redo log同样也是一次磁盘的写操作,凭什么说它的性能就更高一点呢?
写redo log还有刷数据页到磁盘中去,都是磁盘的的写操作,但是呢,将修改信息写入到redo log当中,只需要数据顺序写入redo log当中,这里其实就是一次顺序写磁盘的操作.而将数据页刷到磁盘中,因为一个修改操作可能会同时修改多个数据页,这些数据页又不是连续的,此时就意味着随机写磁盘并且,对于MySQL来说,一个数据页是16kb,可能一次性更新多个数据页,此时可能需要随机写入几百k的数据而对于redo log,一次修改可能只需要写入几k的数据,数据量相对于刷数据页的方式是大大减少的比较一下写redo log和刷数据页,写redo log是磁盘的顺序写,小数据量,而刷数据页到磁盘可能就意味着随机写,而且还是大数据量的,两者一比较,写redo log的性能可能比刷数据页的性能高100倍
综上所述,redo log能够在保证数据不丢失的时候,同时保证了性能
redo log包括两部分:⼀是内存中的⽇志缓冲(redo log buffer),该部分⽇志是易失性的;⼆是磁盘上的重做⽇志⽂件(redo log file),该部分⽇志是持久的。
在概念上,innodb通过force log at commit机制实现事务的持久性,即在事务提交的时候,必须先将该事务的所有事务⽇志写⼊到磁盘上的redo log file和undo log file中进⾏持久化。
为了确保每次⽇志都能写⼊到事务⽇志⽂件中,在每次将log buffer中的⽇志写⼊⽇志⽂件的过程中都会调⽤⼀次操作系统的fsync操作(即fsync()系统调⽤)。因为MariaDB/MySQL是⼯作在⽤户空间的,MariaDB/MySQL的log buffer处于⽤户空间的内存中。要写⼊到磁盘上的log file中(redo:ib_logfileN⽂件,undo:share tablespace或.ibd⽂件),中间还要经过操作系统内核空间的os buffer,调⽤fsync()的作⽤就是将OS buffer中的⽇志刷到磁盘上的log file中。
也就是说,从redo log buffer写⽇志到磁盘的redo log file中,
MySQL中数据是以页为单位,你查询一条记录,会从硬盘把一页的数据加载出来,加载出来的数据叫数据页,会放入到Buffer Pool中。后续的查询都是先从Buffer Pool中找,没有命中再去硬盘加载,减少硬盘IO开销,提升性能。更新表数据的时候,也是如此,发现Buffer Pool里存在要更新的数据,就直接在Buffer Pool里更新。然后会把“在某个数据页上做了什么修改”记录到重做日志缓存(redo log文件)里,接着刷盘到redo log文件里。
binlog redolog区别:
假设一个事务,对表做10万行的记录插入,在这个过程中,一直不断的往redolog