商业网站的后缀设计师培训经历怎么写

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

商业网站的后缀,设计师培训经历怎么写,武昌做网站报价,网络营销与网络推广的异同前言 MySQL实现事务、崩溃恢复、集群的主从复制#xff0c;底层都离不开日志#xff0c;所以日志是MySQL的精华所在。只有了解MySQL日志#xff0c;才算是彻底搞懂MySQL。
日志是mysql数据库的重要组成部分#xff0c;记录着数据库运行期间各种状态信息。mysql日志主要包…前言 MySQL实现事务、崩溃恢复、集群的主从复制底层都离不开日志所以日志是MySQL的精华所在。只有了解MySQL日志才算是彻底搞懂MySQL。  日志是mysql数据库的重要组成部分记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。 我们重点需要关注的是MySQL的三大日志系统Redo Log重做日志、Undo Log恢复日志、Bin Log二进制日志文件。 一、Redo Log重做日志 1.1为什么需要redo log 事务的四大特性里面有一个是持久性具体来说就是只要事务提交成功那么对数据库做的修改就被永久保存下来了不可能因为任何原因再回到原来的状态。那么mysql是如何保证一致性的呢最简单的做法是在每次事务提交的时候将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题主要体现在两个方面 因为Innodb是以页为单位进行磁盘交互的而一个事务很可能只修改一个数据页里面的几个字节这个时候将完整的数据页刷到磁盘的话太浪费资源了 一个事务可能涉及修改多个数据页并且这些数据页在物理上并不连续使用随机IO写入性能太差
因此mysql设计了redo log具体来说就是只记录事务对数据页做了哪些修改这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。 作用概述Redo Log就是用来保证服务崩溃后仍能把事务中变更的数据持久化到磁盘上。 MySQL事务中持久性就是使用Redo Log实现的。 1.2什么时候写入Redo Log  从磁盘加载数据到内存在内存中修改数据把新数据写到Redo Log Buffer中把Redo Log Buffer中数据持久化到Redo Log文件中把Redo Log文件中数据持久化到数据库磁盘中 你可能会问为什么需要写Redo Log Buffer和Redo Log FIle直接持久化到磁盘不好吗 直接写磁盘会有产生严重的性能问题 InnoDB在磁盘中存储的基本单元是页可能本次修改只变更一页中几个字节但是需要刷新整页的数据就很浪费资源。一个事务可能修改了多页中的数据页之间又是不连续的就会产生随机IO性能更差。 这种方案叫做WALWrite-Ahead Logging预写日志就是先写日志再写磁盘。 1.3redo log基础概述 redo log包含了两个层面 内存层面redo log buffer重做日志的buffer由redolog block组成一个16MB物理磁盘层面 (redolog file) 重做日志文件id_logfile0,id_logfile1 redolog的整体流程 还没提交就在写log。redolog的优先级跟高。 注意redo log buffer刷盘到redo logfile的过程并不是真正的刷盘只是刷入到文件缓存中这个是操作系统提高文件写入效率的优化。 但是这种就会出现交给系统刷盘不及时宕机造成数据丢失。 1.4redo log刷盘规则 写入Redo Log Buffer之后并不会立即持久化到Redo Log FIle需要等待操作系统调用fsync()操作才会刷到磁盘上。 具体什么时候可以把Redo Log Buffer刷到Redo Log FIle中可以通过innodb_flush_log_at_trx_commit参数配置决定。 参数值含义0延迟写提交事务后不会立即刷到OS Buffer中而是等一秒后刷新到OS Buffer并调用fsync()写入Redo Log FIle可能会丢失一秒钟的数据。1实时写每次提交事务都会刷新到OS Buffer并调用fsync()写到Redo Log FIle性能较差2延迟刷新每次提交事务只刷新到OS Buffer一秒后再调用fsync()写入Redo Log FIle。 InnoDB 的Redo Log File是固定大小的。可以配置为每组4个文件每个文件的大小是 1GB那么Redo Log File可以记录4GB的操作。 采用循环写入覆盖的方式write pos记录开始写的位置向后移动。checkpoint记录将要擦除的位置也是向后移动。write pos到checkpoint之间的位置是可写区域checkpoint到write pos之间的位置是已写区域。 Redolog小结
1.5redo log与binlog区别 由bin log和redo log的区别可知 bin log日志只用于归档只依靠bin log是没有crash-safe能力的。但只有redo log也不行因为redo log是InnoDB特有的且日志上的记录落盘后会被覆盖掉。因此需要bin log和redo log二者同时记录才能保证当数据库发生宕机重启时数据不会丢失。redolog是存储引擎层产生的而binlog 是数据层层面产生的。假设一个事务对表做了10万行的记录插入在这个过程中一直不断的往redo log顺序记录而bin log不会只有事务提交后才一次性写入binlog日志。功能redo log:让innodb存储引擎拥有崩溃恢复能力bin log:保证了Mysql集群架构的数据一致性。 二、Undo Log恢复日志 2.1为什么引入undo log? 为了保证事务的原子性既事务中的操作要么全部做完要么都不做。如果事务执行中突发异常如数据库出错、操作系统宕机等亦或者程序员要在事务执行过程中结束当前事务的执行如何保证事务的原子性呢 这就需要在对一条记录做变更增删改不包括查时都要把能回滚的内容记录下来以备不时之需回滚的时候只需要对数据库进行一个相反的操作即可。 新增一条记录记录下主键回滚时直接DELETE这个主键的内容;删除一条记录记录下被删记录的内容回滚时可以将内容再插入表中修改一条记录记录下修改之前的旧值回滚时直接更新为旧值。 2.2undo log的作用 回滚数据undo log记录了每个操作的逆操作可以逻辑恢复数据注意类似git 操作不是物理上的恢复既数据结构和页可能变化了MVCC在InnoDB中MVCC的实现是通过undo log来完成。当用户读取一行记录时若该记录已经被其他事务占用当前事务可以通过undo log读取之前的行版本信息以此实现非锁定读取。 2.3undo log的类型 在InnoDB中undo log分为两种 insert undo log是指在insert操作中产生的undo log。因为insert操作的记录只对当前事务本身可见对其他事务不可见(这是事务隔离性的要求)因此这种undo log可以在事务提交后直接删除。不需要进行purge操作。undate undo log是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制使用因此不能在事务提交时就进行删除提交时放入undo log链表等待purge线程进行最后的删除。 2.4undo log的生命周期  MySQL处于性能考虑数据会优先从磁盘加载到Buffer Pool中在更新Buffer Pool中数据之前会优先将数据记录到undo log中。 记录undo log日志MySQL不会直接去往磁盘中的xx.ibdata文件写数据而是会写在undo_log_buffer缓冲区中因为工作线程直接去写磁盘太影响效率了写进缓冲区后会由后台线程去刷写磁盘。 2.5删除过程 现在我们已经明白了undo log日志是如何生成并且作用于事务回滚的那这些数据是什么时候删除呢 针对于insert undo log因为insert操作的记录只对事务本身可见对其他事务不可见。故该undo log在事务提交后就没有用就会直接删除。针对于update undo log该undo log需要支持MVCC机制因此不能在事务提交时就进行删除。提交时放入undo log链表有专门的purge线程进行删除。 三、Bin Log二进制日志文件 3.1bin log基本概述 即binary log二进制日志文件也叫作变更日志update log是MySQL中比较重要的日志和运维息息相关。它记录了所有更新数据库的语句如DDL和 DML语句并以二进制的形式保存在磁盘中但是不包含没有修改任何数据的语句如数据查询语句select、show等。 bin log是逻辑日志记录的是执行语句的逻辑和redis的AOP日志类似会按顺序记录所有涉及更新数据的逻辑操作。 3.2主要作用 数据恢复MySQL可以通过bin log恢复某一时刻的误操作的数据是DBA常打交道的日志。数据复制MySQL的数据备份、集群高可用、读写分离都是基于bin log的重放实现的。 3.3记录格式 binlog日志有三种格式statement、row和mixed对比如下 格式含义优点缺点statement每一条会修改数据的sql都会记录在binlog中,基于SQL语句的复制记录的是更新数据操作的SQL语句这些语句同步时会被其他节点执行如update T set timeNOW() where id 1;不需要记录每一行的变化减少了binlog日志量节约了IO, 提高了性能。由于记录的只是执行语句为了这些语句能在slave上正确运行因此还必须记录每条语句在执行的时候的一些相关信息以保证所有语句能在slave得到和在master端执行的时候相同的结果。另外mysql的复制像一些特定函数的功能slave与master要保持一致会有很多相关问题。row5.1.5版本的MySQL才开始支持 row level 的复制,它不记录sql语句上下文相关信息仅保存哪条记录被修改。binlog中可以不记录执行的sql语句的上下文相关的信息仅需要记录那一条记录被修改成什么了。所以row的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题。每条数据的更改被详细记录如整表删除alter表等操作涉及的数据行都会记录ROW格式会产生大量日志。mixed混合模式5.1.8版本开始以上两种格式的混合版对于DDL只对SQL语句进行记录对DML操作则会进行判断如果判断会造成主从不一致就会采用row格式记录反之则用statement格式记录。既节省空间又提高数据库性能保证数据同步时的一致性。无法对误操作数据进行单独恢复。 注将二进制日志格式设置为ROW时有些更改仍然使用基于语句的格式包括所有DDL语句例如CREATE TABLE ALTER TABLE或 DROP TABLE。 3.4Binlog结构和内容 日志由一组二进制日志文件Binlog)加上一个索引文件indexBinlog是一个二进制文件集合每个Binlog以一个4字节的魔数开头接着是一组Events。 魔数0xfe62696e对应的是0xfebinEvent每个Event包含header和data两个部分header提供了Event的创建时间哪个服务器等信息data部分提供的是针对该Event的具体信息如具体数据的修改第一个Event用于描述binlog文件的格式版本这个格式就是event写入binlog文件的格式其余的Event按照第一个Event的格式版本写入最后一个Event用于说明下一个binlog文件Binlog的索引文件是一个文本文件其中内容为当前的binlog文件列表