概述
还有Mysql底层的几种主要日志,比如binlog,redo log,undo log等,这些日志有什么作用以及底层实现原理是什么,还有生产环境最佳配置
MySQL三大日志包括:undolog,redo log,binlog,
undolog:是Innodb存储引擎生成的日志。用于事务的回滚和MVCC,保证了事务的原子性。
redolog:是Innodb存储引擎生成的日志。用于崩溃后修复数据,保证了事务的持久性。
binlog:是Server层生成的日志。用于备份数据,集群等。
undo的会清理 redolog是覆盖 binlog是需要自己清理的
innodb 两种日志 redo 和 undo。
redo:在页修改的时候,先写到 redo log buffer 里面, 然后写到 redo log 的文件系统缓存里面(fwrite),然后再同步到磁盘文件( fsync)。
Undo:在 MySQL5.5 之前, undo 只能存放在 ibdata 文件里面, 5.6 之后,可以通过设置 innodb_undo_tablespaces 参数把 undo log 存放在 ibdata 之外。
事务是如何通过日志来实现的
因为事务在修改页时,要先记 undo,在记 undo 之前要记 undo的 redo, 然后修改数据页,再记数据页修改的redo。 Redo(里面包括 undo 修改) 一定要比数据页先持久化到磁盘。
当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的状态,崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo 把该事务修改回滚到事务开始之前。如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。
undo log 具体怎么回滚事务
对于 insert 类型的 sql,会在 undo log 中记录下方才你 insert 进来的数据的 ID,当你想
roll back 时,根据 ID 完成精准的删除。
对于 delete 类型的 sql,会在 undo log 中记录方才你删除的数据,当你回滚时会将删除
前的数据 insert 进去。
对于 update 类型的 sql,会在 undo log 中记录下修改前的数据,回滚时只需要反向
update 即可。
对于 select 类型的 sql,别费心了,select 不需要回滚。
MySQL 的 Binlog 有有几种录入格式?分别有什么区别?
有三种格式,statement,row 和 mixed。
statement 模式下,每一条会修改数据的 sql 都会记录在 binlog 中。不需要记录每一行
的变化,减少了 binlog 日志量,节约了 IO,提高性能。由于 sql 的执行是有上下文的, 因此在保存的时候需要保存相关的信息,同时还有一些使用了函数之类的语句无法被记录 复制。
row 级别下,不记录 sql 语句上下文相关信息,仅保存哪条记录被修改。记录单元为每一
行的改动,基本是可以全部记下来但是由于很多操作,会导致大量行的改动(比如 alter table),因此这种模式的文件保存的信息太多,日志量太大。
mixed,一种折中的方案,普通操作使用 statement 记录,当无法使用 statement 的时
候使用 row