大气网站建设,怎样清理网站后门,小企业网页制作,购物网站建设基本流程概念
1 什么是脏页#xff1f; 对于数据库中页的修改操作#xff0c;则首先修改在缓冲区中的页#xff0c;缓冲区中的页与磁盘中的页数据不一致#xff0c;所以称缓冲区中的页为脏页。 2 脏页什么时候写入磁盘#xff1f; 脏页以一定的频率将脏页刷新到磁盘上。页从缓冲区…概念
1 什么是脏页 对于数据库中页的修改操作则首先修改在缓冲区中的页缓冲区中的页与磁盘中的页数据不一致所以称缓冲区中的页为脏页。 2 脏页什么时候写入磁盘 脏页以一定的频率将脏页刷新到磁盘上。页从缓冲区刷新回磁盘的操作并不是在每次页发生更新时触发而是通过一种称为CheckPoint的机制刷新回磁盘。 3 什么是CheckPoint Checkpoint要做的事情是将缓冲池中的脏页数据刷到磁盘上。CheckPoint决定了脏页落盘的时机、条件及脏页的选择不同的CheckPoint做法并不相同。
保证数据的安全性
落盘的流程图
脏页产生了肯定是有一个时间要进行落盘那么怎么保证修改内存到落盘整个过程中不发生任何的问题呢
InnoDB采用了Write Ahead LogWAL策略和Force Log at Commit机制实现事务级别下数据的持久性。 Force Log at Commit机制当事务提交时所有事务产生的日志都必须刷到磁盘。如果日志刷新成功后缓冲池中的数据刷新到磁盘前数据库发生了宕机那么重启时数据库可以从日志中恢复数据,这样可以保证数据的安全性,这个是mysql redo log 落盘的默认行为innodb_flush_log_at_trx_commit 可以通过这个参数去改变。 Write Ahead LogWAL策略:要求数据的变更写入到磁盘前首先必须将内存中的日志写入到磁盘InnoDB 的 WALWrite Ahead Log技术的产物就是 redo log对于写操作永远都是日志先行先写入 redo log 然后在合适的时间应用redo log进行刷盘。 redo log日志只记录更新操作和行信息大小相对较小。同时日志的写入是顺序的就是继续往后写这样通过日志先行就把随机的写入转换为了顺序写入从而提升了性能。再有日志的刷盘和事务是有关联的事务提交后刷盘策略可以通过innodb_flush_log_at_trx_commit 来控制日志记录的是事务中执行的一系列操作不是单条就会触发更新。 Redo Log 刷盘的时机 1Mysql服务关闭时 2当 redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半时会触发落盘 3InnoDB 的后台线程每隔 1 秒将 redo log buffer 持久化到磁盘。 4每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘这里可以调整策略。 为了确保每次日志都写入到redo日志文件在每次将redo日志缓冲写入redo日志后调用一次fsync操作从系统的缓存真正刷新到磁盘将缓冲文件从文件系统缓存中真正写入磁盘。
innodb_flush_log_at_trx_commit 这个参数相信也不陌生了 0时事务提交时不会立即把 log buffer里的数据写入到redo log日志文件的。而是等待主线程每秒写入一次。 特点 如果MySQL崩溃或者服务器宕机此时内存里的数据会全部丢失最多会丢失1秒的事务。 写入效率最高但是数据安全最低 1时每次事务提交时会将数据将从log buffer写入redo日志文件与文件系统缓存并同时 fsync刷新到磁盘中。 特点 系统默认配置为1MySQL崩溃已经提交的事务不会丢失要完全符合ACID必须使用默认设置1。 写入效率最低但是数据安全最高 2时事务提交时也会将数据写入redo日志文件与文件系统缓存但是不会调用fsync而是让 操作系统自己去判断何时将缓存写入磁盘。 特点 事务提交都会将数据刷新到操作系统缓冲区可以认为是已经持久化到磁盘但没有真正意义 上持久化到磁盘。 如果MySQL崩溃已经提交的事务不会丢失。但是如果服务器宕机或者意外断电操作系统缓存内的数据会丢失所以最多丢失1秒的事务。
检查点机制
有了上面的准备工作真正决定数据什么时候落盘的时机是检查点机制下面我们来看看检查点是怎样工作的解决了什么问题 1 从这个流程来看首先它可以避免Redo log日志的堆积。因为我们当前检查点执行以后数据已经落盘了那么之前的Redo log就没有作用了可以清理掉不可能再使用到的日志。同时如果数据库发了宕机这个时候也只需要执行上一个检查点到现在的Redo Log就可以恢复数据。 2 可以解决缓冲池不够用问题缓冲池不够用时将脏页刷新到磁盘当缓冲池不够用时根据LRU算法会溢出最近最少使用的页若此页为脏页那么需要强制执行Checkpoint将脏页也就是页的新版本刷回磁盘。 3 redo日志不可用时刷新脏页当redo日志出现不可用时Checkpoint将缓冲池中的页至少刷新到当前redo日志的位置。这样就算RedoLog不可用也可以保证不丢失更新。
那么具体的检查点又有所不同 1 可以分为两类 sharp checkpoint在关闭数据库的时候将buffer pool中的脏页全部刷新到磁盘中。 fuzzy checkpoint数据库正常运行时在不同的时机将部分脏页写入磁盘。仅刷新部分脏页到磁盘也是为了避免一次刷新全部的脏页造成的性能问题。
Fuzzy Checkpoint默认方式只刷新一部分脏页不是刷新所有脏页 主要有以下几种情况
Master Thread Checkpoint 在Master Thread中会以每秒或者每10秒一次的频率将部分脏页从内存中刷新到磁盘这个过程是异步的。正常的用户线程对数据的操作不会被阻塞。FLUSH_LRU_LIST Checkpoint缓冲池不够用时根据LRU算法会淘汰掉最近最少使用的页如果该页是脏页的话会强制执行CheckPoint将该脏页刷回磁盘由Page Cleaner Thread完成Async/Sync Flush Checkpoint重做日志不可用的情况需要强制从脏页列表中选取一些脏页刷盘由Page Cleaner Thread完成。由于磁盘是一种相对较慢的存储设备内存与磁盘的交互是一个相对较慢的过程。innodb_log_file_size定义的是一个相对较大的值正常情况下由前面两种checkpoint刷新脏页到磁盘在前面两种checkpoint刷新脏页到磁盘之后脏页对应的redo log空间随即释放一般不会发生Async/Sync Flush checkpoint。Dirty Page too much即脏页数量太多导致强制进行Checkpoint。由参数innodb_max_dirty_pages_pt 来控制默认75即75%。当脏页数量占据75%缓冲池时刷新一部分脏页到磁盘。由Page Cleaner Thread完成
在检查点落盘的过程中也可能会发生异常这个时候就需要Double Write双写来保证不写失效 所谓的写失效就就比如我们一页的数据为16K,但是我们这个页只写了一半数据库就发生了异常这个时候页就被损坏了。 这个时候我们不能通过Redo log来恢复重做日志中记录的是对页的物理操作而不是页面的全量记录而如果发生partial page write部分页写入问题时出现问题的是未修改过的数据此时重做日志(Redo Log)无能为力。因此引入了双写机制 Double Write分两个部分 内存中的Doublewrite buffer大小为2MB 磁盘上的Doublewrite buffer大小为2MB连续的128个页相当于两个extent Double write脏页刷新流程 1 首先复制脏页刷新时不直接写磁盘而是先将脏页复制到内存的Doublewrite buffer。 2 再顺序写内存的Doublewrite buffer分两次每次1MB顺序地写入共享表空间的物理磁盘上会立即调用fsync函数同步OS缓存到磁盘中顺序写性能好。 3 最后离散写内存的Doublewrite buffer最后将页写入各自表空间文件中离散写较顺序写入差一些。 如果操作系统在将页写入磁盘的过程中发生了崩溃其恢复过程如下 1 首先InnoDB存储引擎从系统表空间中的Double write中找到该页的一个副本 2 然后将其复制到独立表空间 3 再应用重做日志。 相关配置 innodb_doublewriteDoublewrite Buffer是否启用开关默认是开启状态InnoDB将所有数据存储两次首先到双写缓冲区然后到实际数据文件。 Innodb_dblwr_pages_written记录写入到DWB中的页数量。 Innodb_dblwr_writes记录DWB写操作的次数。
