技术日志挑战——第17天:0809

2024-08-09 23:23:19 浏览数 (1)

技术总结:

今天是周五,天气是在太热了,就没有去上班,在家办公了一天,不过好像也没做什么工作方面的事情。明天打算去公司一趟,把进度补一补。

学习笔记:


**bin log用于备份恢复、主从复制;

redo log用于掉电等故障恢复。**

(1) 如果不小心整个数据库的数据被删除了,能使用redo log文件恢复数据吗?

不可以使用redo log文件恢复,只能使用binlog文件恢复。

因为redo log文件是循环写,是会边写边擦除日志的,只记录未被刷入磁盘的数据的物理日志,已经刷入磁盘的数据都会从redo log文件里擦除。

binlog文件保存的是全量的日志,也就是保存了所有数据变更的情况,理论上只要记录在binlog上的数据,都可以恢复,所以如果不小心整个数据库的数据被删除了,得用binlog文件恢复数据。

(2) MySQL在完成一条更新操作后,Server.层会生成一条binlog,Bin Log也是采用WL模式,先写日志,再写磁盘。

事务执行过程中,先把日志写到binlog cache,事务提交的时候,再把binlogcache写到binlog文件中。

因为一个事务的binlog?不能被拆开,无论这个事务多大,也要确保一次性写入,所以系统会给每个线程分配一块内存作为binlog cache。

至于什么时候刷新到磁盘,可以sync_binlog配置参数指定。

  • 0(延迟写)每次提交事务都不会刷盘,由系统自己决定什么时候刷盘,可能会丢失数据。
  • 1(实时写)每次提交事务,都会刷盘,性能较差。
  • N(延迟写)提交N个事务后,才会刷盘。

加入写Bin Log.之后的事务流程,先写处于prepare状态的Redo Log,事务提交后,再写处于commit状态的Redo Log,这就是二阶段提交的概念。

0 人点赞