We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
redo是引擎层的日志,而且是InnoDB特有的。InnoDB的redo log是有固定大小的,比如可以配置为 一组4个文件(logfile-1,logfile-2,logfile-3,logfile-4),每个文件的大小是1GB,那么它总共可以记录4GB的操作。一个环状循环结构,从头开始写,写到末尾又回到开始循环写。
redo
redo log
结构图:
write pos是当前记录的位置,一边写一边后移,环状结构,写到3号文件末尾就会回到0号文件开头。checkpoint是当前擦除的位置,也是往后推移并且循环的。注意擦除记录前要把记录更新到数据文件(这里可以联想 粉板 老板正式记账本的例子)
write pos
WAL
write-Ahead-Logging
先写日志,再写磁盘
crash-safe
Mysql基础架构整体分为两部分:Server层和引擎层,引擎层主要负责存储相关的事宜。上面说到在引擎层有自己的日志,而且只在InnoDB引擎中才有。Server层也有自己的日志,称为binlog(归档日志)。它是采用追写入日志的方式。追加写是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。
只依靠redo日志的crash-safe特性在应对数据库误删,表数据误删等操作时候,有些时候redo日志是无力的,但是binlog日志解决这些问题,因为binlog会记录所有的逻辑操作,并且采用“追加写”的形式。
举个例子如果公司员工发现某天下午有一个误删表数据操作,要求找回数据,应该怎么做?(注:这里要考虑是在刚备份之后误删除,还是备份之前误删除,下面的例子是在备份之前删除的,找之前删除的数据)
redo日志与binlog日志有哪些不同? 其实上面好多都提到过,再次总结一遍,加深印象。
环状结构
数据库语句:
mysql> update Student set c=c+1 where ID=2;
通过分析这一条更新语句,画出流程图,问题3也就得到解决。
注意流程图的最后三步,这是更新语句和日志关系密切的地方,将redo日志拆成了两个步骤:prepare和commit,它俩的中间是执行器写入binlog。(注:如果不这么做,假如一个日志提交成功的时候,另一个日志提交之前发生了数据库发生了崩溃,但是crash-safe恢复或者误删库恢复的时候可能造成二者数据不统一出现问题。)
innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1,这样可以保证 MySQL 异常重启之后数据不丢失。
innodb_flush_log_at_trx_commit
binlog
sync_binlog 这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1,这样可以保证 MySQL 误删除操作(删除表数据,删除库数据) 通过binlog 仍可恢复。
大家会不会想有了redo日志就可以了,为什么还要出现binlog日志呢?
解答:
这里有一个问题:如果在擦除和记账重合那一刻,数据库异常重启了,新的数据库操作会怎么记录,是擦除一部分,记录上,会丢失,还是等待重启后往上添加数据?
关于数据库备份,是一天一备比较好,还是一周一备份比较好,一般备份文件保留多久?提出问题4解决
解答:对于数据库备份周期这个问题,需要考虑以下指标:数据存量、增量、备份成本、恢复效率。
总的来说就是和项目,需求,场景有很多关系。
写入redo日志也是io操作,数据更新直接写入磁盘也是io操作,为什么说写入redo日志效率高节省io成本呢?
解答:redo日志的写入是顺序写入的,不用去“找位置”,而直接更新数据到磁盘的话,需要到磁盘中找到位置再写入,肯定前者的效率高。
以上内容是关于数据库日志系统的讲解,同时解决了我开篇提出的几个数据库日志相关的问题,希望能帮助大家更好的了解学习数据库,如果有问题可以随时关注公众号联系,互相学习哦。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
提出问题?
接下来在讲解日志系统的同时,回答上面的几个问题。
日志系统详解:
redo日志(重做日志)
redo
是引擎层的日志,而且是InnoDB特有的。InnoDB的redo log
是有固定大小的,比如可以配置为 一组4个文件(logfile-1,logfile-2,logfile-3,logfile-4),每个文件的大小是1GB,那么它总共可以记录4GB的操作。一个环状循环结构,从头开始写,写到末尾又回到开始循环写。redo中的环状结构
结构图:
write pos
是当前记录的位置,一边写一边后移,环状结构,写到3号文件末尾就会回到0号文件开头。checkpoint是当前擦除的位置,也是往后推移并且循环的。注意擦除记录前要把记录更新到数据文件(这里可以联想 粉板 老板正式记账本的例子)redo日志作用(回答提出问题1)
WAL
的全称是write-Ahead-Logging
,它的关键点就是先写日志,再写磁盘
。具体说,当有一条记录需要更新的时候,InoDB引擎会先记录到redo log,并更新内存,这时候更新就算完成了。同时InnoDb引擎会在适当的时候,将这个操作记录更新到磁盘里面,而这个更新往往是在系统比较空闲的时候做。crash-safe
。只要数据库的物理记录还在redo log中,就是服务器数据库出现问题重启,数据库恢复后,数据记录仍然可以恢复。binlog日志(归档日志)
Mysql基础架构整体分为两部分:Server层和引擎层,引擎层主要负责存储相关的事宜。上面说到在引擎层有自己的日志,而且只在InnoDB引擎中才有。Server层也有自己的日志,称为binlog(归档日志)。它是采用追写入日志的方式。追加写是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。
binlog日志作用(回答提出问题2)
只依靠redo日志的crash-safe特性在应对数据库误删,表数据误删等操作时候,有些时候redo日志是无力的,但是binlog日志解决这些问题,因为binlog会记录所有的逻辑操作,并且采用“追加写”的形式。
举个例子如果公司员工发现某天下午有一个误删表数据操作,要求找回数据,应该怎么做?(注:这里要考虑是在刚备份之后误删除,还是备份之前误删除,下面的例子是在备份之前删除的,找之前删除的数据)
redo日志与binlog日志对比
redo日志与binlog日志有哪些不同?
其实上面好多都提到过,再次总结一遍,加深印象。
环状结构
,循环写,空间固定会用完,用完后需要擦除;binlog是可以追加写入的。“追加写”是只belog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。更新语句执行流程(与日志关系)
数据库语句:
通过分析这一条更新语句,画出流程图,问题3也就得到解决。
注意流程图的最后三步,这是更新语句和日志关系密切的地方,将redo日志拆成了两个步骤:prepare和commit,它俩的中间是执行器写入binlog。(注:如果不这么做,假如一个日志提交成功的时候,另一个日志提交之前发生了数据库发生了崩溃,但是crash-safe恢复或者误删库恢复的时候可能造成二者数据不统一出现问题。)
开发过程中如何为mysql设置这两种保存日志的配置
redo log
innodb_flush_log_at_trx_commit
这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1,这样可以保证 MySQL 异常重启之后数据不丢失。binlog
sync_binlog 这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1,这样可以保证 MySQL 误删除操作(删除表数据,删除库数据) 通过binlog 仍可恢复。
如何查看这两种日志
关于日志系统的一些误区和疑问
大家会不会想有了redo日志就可以了,为什么还要出现binlog日志呢?
解答:
这里有一个问题:如果在擦除和记账重合那一刻,数据库异常重启了,新的数据库操作会怎么记录,是擦除一部分,记录上,会丢失,还是等待重启后往上添加数据?
关于数据库备份,是一天一备比较好,还是一周一备份比较好,一般备份文件保留多久?提出问题4解决
解答:对于数据库备份周期这个问题,需要考虑以下指标:数据存量、增量、备份成本、恢复效率。
总的来说就是和项目,需求,场景有很多关系。
写入redo日志也是io操作,数据更新直接写入磁盘也是io操作,为什么说写入redo日志效率高节省io成本呢?
解答:redo日志的写入是顺序写入的,不用去“找位置”,而直接更新数据到磁盘的话,需要到磁盘中找到位置再写入,肯定前者的效率高。
总结与宣传
以上内容是关于数据库日志系统的讲解,同时解决了我开篇提出的几个数据库日志相关的问题,希望能帮助大家更好的了解学习数据库,如果有问题可以随时关注公众号联系,互相学习哦。
The text was updated successfully, but these errors were encountered: