手机网站首页经典案例做网站备负责人风险大吗

当前位置： 首页 > news >正文

手机网站首页经典案例,做网站备负责人风险大吗,北京品牌网站建设公司,门户网站建设情况自查汇报redo log的工作原理 前言概念为什么需要redo log修改undo页面,会记录对应的redo log吗redo log 和undo log 区别在哪什么是WAL技术redo log要写入磁盘,数据也要写入磁盘,为什么多此一举产生的redo log直接写入磁盘吗redo log 什么时候刷盘innodb_flush_log_at_trx_commit 参数参… redo log的工作原理 前言概念为什么需要redo log修改undo页面,会记录对应的redo log吗redo log 和undo log 区别在哪什么是WAL技术redo log要写入磁盘,数据也要写入磁盘,为什么多此一举产生的redo log直接写入磁盘吗redo log 什么时候刷盘innodb_flush_log_at_trx_commit 参数参数为0 和2时,什么时候将redo log 写入到磁盘.应用场景是什么 redo log 文件写满了怎么办总结 前言 你知道什么是存储引擎、随机 IO 和顺序 IO吗你知道 MySQL 中的缓冲池吗binlog 听说过吗都有什么用 如果你对上面的问题还有疑问或者没听过,建议你先去看一下相关的知识点再来看本章内容(我前面文章都有聊过这些内容,你可以看一下). 概念 Redo Log一种物理日志记录对数据页的修改内容用于保证事务的持久性和数据库或操作系统崩溃后的故障恢复。内部记录了需要修改的数据页、页中数据的偏移量、修改的字段和修改的值。 比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新. 每当执行一个事务就会产生这样的一条或者多条物理日志。 在事务提交时只要先将 redo log 持久化到磁盘即可可以不需要等到将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。 当系统崩溃时虽然脏页数据没有持久化但是 redo log 已经持久化接着 MySQL 重启后可以根据 redo log 的内容将所有数据恢复到最新的状态。 为什么需要redo log 数据页在缓冲池中被修改会变成脏页。如果这时宕机脏页就会失效这就导致我们修改的数据丢失了也就无法保证事务的持久性。保证数据不丢. 为了防止断电导致数据丢失的问题当有一条记录需要更新的时候InnoDB 引擎就会先更新内存同时标记为脏页然后将本次对这个页的修改以 redo log 的形式记录下来这个时候更新就算完成了。 就是 redo log 的一个重要功能。 修改undo页面,会记录对应的redo log吗 需要的. 开启事务后InnoDB 层更新记录前首先要记录相应的 undo log,开启事务后InnoDB 层更新记录前首先要记录相应的 undo log. 开启事务后InnoDB 层更新记录前首先要记录相应的 undo log. redo log 和undo log 区别在哪 这两种日志是属于 InnoDB 存储引擎的日志它们的区别在于 redo log 记录了此次事务「修改后」的数据状态记录的是更新之后的值主要用于事务崩溃恢复保证事务的持久性。undo log 记录了此次事务「修改前」的数据状态记录的是更新之前的值主要用于事务回滚保证事务的原子性。 事务提交之前发生了崩溃这里的崩溃不是宕机崩溃而是事务执行错误mysql 还是正常运行的。如果是宕机崩溃的话其实就不需要通过 undo log 回滚了因为事务没有提交事务的数据并不会持久化还是在内存中宕机崩溃了数据就丢失了因为事务没有提交事务的数据并不会持久化还是在内存中宕机崩溃了数据就丢失了),重启后会通过 undo log 回滚事务。 事务提交之后发生了崩溃这里的崩溃是宕机崩溃重启后会通过 redo log 恢复事务如下图 所以有了 redo log再通过 WAL 技术InnoDB 就可以保证即使数据库发生异常重启之前已提交的记录都不会丢失这个能力称为 crash-safe崩溃恢复。 可以看出来 redo log 保证了事务四大特性中的持久性。 什么是WAL技术 WAL全名为Write-Ahead Logging是一种在数据库系统中用于保证数据持久性和恢复性的技术。 在数据库操作中数据的写入操作不是直接写入到磁盘中而是先写入一个WAL日志文件然后再写入到磁盘中。 redo log要写入磁盘,数据也要写入磁盘,为什么多此一举 写入 redo log 的方式使用了追加操作 所以磁盘操作是顺序写. 写入数据需要先找到写入位置然后才写到磁盘所以磁盘操作是随机写。 磁盘的「顺序写 」比「随机写」 高效的多因此 redo log 写入磁盘的开销更小,提升语句的执行性能,然后在合适的时间再更新到磁盘上. 简单来说如下: 实现事务的持久性让 MySQL 有 crash-safe 的能力.将写操作从「随机写」变成了「顺序写」提升 MySQL 写入磁盘的性能. 产生的redo log直接写入磁盘吗 不是的. 如果直接写入磁盘这样会产生大量的 I/O 操作而且磁盘的运行速度远慢于内存。 所以redo log 也有自己的缓存—— redo log buffer. 所以redo log 也有自己的缓存—— redo log buffer. redo log buffer 默认大小 16 MB可以通过 innodb_log_Buffer_size 参数动态的调整大小增大它的大小可以让 MySQL 处理「大事务」是不必写入磁盘进而提升写 IO 性能。 redo log 什么时候刷盘 缓存在 redo log buffer 里的 redo log 还是在内存中它什么时候刷新到磁盘. 主要有下面几个时机 MySQL 正常关闭时当 redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半时会触发落盘InnoDB 的后台线程每隔 1 秒将 redo log buffer 持久化到磁盘。每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘. innodb_flush_log_at_trx_commit 参数 默认行为: 单独执行一个更新语句的时候InnoDB 引擎会自己启动一个事务. 在执行更新语句的过程中生成的 redo log 先写入到 redo log buffer 中,在执行更新语句的过程中生成的 redo log 先写入到 redo log buffer 中. InnoDB 还提供了另外两种策略由参数innodb_flush_log_at_trx_commit控制,可取的值有0、1、2默认值为 1,这三个值分别代表的策略如下: 当设置该参数为 0 时 每次事务提交时 还是将 redo log 留在 redo log buffer 中,该模式下在事务提交时不会主动触发写入磁盘的操作。当设置该参数为 1 时 每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘这样可以保证 MySQL 异常重启之后数据不会丢失。当设置该参数为 2 时 每次事务提交时都只是缓存在 redo log buffer 里的 redo log写到 redo log 文件注意写入到「 redo log 文件」并不意味着写入到了磁盘因为操作系统的文件系统中有个 Page CachePage Cache 是专门用来缓存文件数据的所以写入「 redo log文件」意味着写入到了操作系统的文件缓存。 如下图:
参数为0 和2时,什么时候将redo log 写入到磁盘. InnoDB 的后台线程每隔 1 秒: 参数0 会把缓存在 redo log buffer 中的 redo log 通过调用 write() 写到操作系统的 Page Cache,然后调用 fsync() 持久化到磁盘。 MySQL 进程的崩溃会导致上一秒钟所有事务数据的丢失;参数1 调用 fsync将缓存在操作系统中 Page Cache 里的 redo log 持久化到磁盘. 较取值为 0 情况下更安全因为 MySQL 进程的崩溃并不会丢失数据只有在操作系统崩溃或者系统断电的情况下,上一秒钟所有事务数据才可能丢失. 刷盘时机如下图:
应用场景是什么 数据安全性参数 1 参数 2 参数 0 写入性能参数 0 参数 2 参数 1 数据安全性和写入性能是熊掌不可得兼的 对数据安全性要求比较高的场景中,参数1 合适可以容忍数据库崩溃时丢失 1s 数据的场景中,参数0合适安全性和性能折中的方案就是参数 2 redo log 文件写满了怎么办 默认情况下 InnoDB 存储引擎有 1 个重做日志文件组( redo log Group「重做日志文件组」由有 2 个 redo log 文件组成这两个 redo 日志的文件名叫 ib_logfile0 和 ib_logfile1 。 在重做日志组中每个 redo log File 的大小是固定且一致的,在重做日志组.中每个 redo log File 的大小是固定且一致的,假设每个 redo log File 设置的上限是 1 GB那么总共就可以记录 2GB 的操作。 重做日志文件组是以循环写的方式工作的从头开始写写到末尾就又回到开头相当于一个环形。 redo log 是为了防止 Buffer Pool 中的脏页丢失而设计的,Buffer Pool 的脏页刷新到了磁盘中那么 redo log 对应的记录也就没用了,这时候我们擦除这些旧记录以腾出空间记录新的更新操作。 InnoDB 用 write pos 表示 redo log 当前记录写到的位置用 checkpoint 表示当前要擦除的位置.如下图: 图中: write pos 和 checkpoint 的移动都是顺时针方向write pos checkpoint 之间的部分图中的红色部分用来记录新的更新操作check point write pos 之间的部分图中蓝色部分待落盘的脏数据页记录 当write pos checkpoint-意味着edo log 文件满了. 这时 MySQL 不能再执行新的更新操作也就是说 MySQL 会被阻塞,此时会停下来将 Buffer Pool 中的脏页刷新到磁盘中,然后标记 redo log 哪些记录可以被擦除接着对旧的 redo log 记录进行擦除,等擦除完旧记录腾出了空间checkpoint 就会往后移动图中顺时针. 总结 redo log 的核心作用是保证已提交事务的修改不会丢失它是实现事务持久性Durability的关键技术之一。通过记录已提交事务的修改操作并在崩溃后恢复这些操作redo log 能够有效地防止数据丢失确保数据库恢复到一致的状态。