精华内容
下载资源
问答
  • 如果每一次更新都写磁盘,然后磁盘也要找到对应记录,再更新,整个过程的IO成本查找成本都很高。所以InnoDB采取WAL(Write-Ahead Logging)技术,即先写日志,再写磁盘。 当有记录需要更新时,InnoDB引擎先记录...

    redo log(InnoDB)

    • 如果每一次更新都写磁盘,然后磁盘也要找到对应记录,再更新,整个过程的IO成本和查找成本都很高。所以InnoDB采取WAL(Write-Ahead Logging)技术,即先写日志,再写磁盘。
    • 当有记录需要更新时,InnoDB引擎先记录redo log,再更新内存。然后找适当时机将该操作写到磁盘(比如系统空闲时)。
    • redo log的大小是固定的(可配置),比如4个文件,每个文件大小1GB,从第一个文件开始写,写到第四个文件末尾再从头循环。
    • 图片来自Mysql45讲02图片来自Mysql45讲02
    • write pos是当前写到哪里了,check point是当前擦除到哪里了(擦除之前要把记录更新到数据文件),两者间绿色部分是可以写的空间。如果write pos追上了check point,则不能再执行新的更新操作,得先擦除一些记录。
    • 有了redo log,InnoDB可以保证数据库异常重启,之前提交的记录也不会丢失,这个能力称为crash-safe

    binlog

    • redo log是InnoDB引擎特有的,而binlog属于Server层。
    • 最初Mysql自带引擎是MyISAM,但是该引擎没有crash-safe能力,binlog只能用于归档。

    两者不同点

    • 如上所述,redo log是InnoDB特有,binlog所有引擎都可使用(因为所有引擎共用Server层)。
    • redo log是物理日志,记录的是某数据页做了什么修改;binlog是逻辑日志,记录的是语句的原始逻辑,比如给ID=2这一行的c字段加1
    • redo log是循环写的,空间固定会用完(用完后需要擦除记录才能写新的);binlog是追加写,单个文件达到一定大小会切换到下一个,不会覆盖旧的。

    更新语句流程

    update T set c=c+1 where ID=2;

    • 执行器先找到ID=2这一行,ID是主键,引擎用树搜索找到这一行。如果该行所在数据页本来就在内存中,就直接返回给执行器。否则,需要先从磁盘读入内存,再返回。
    • 执行器拿到引擎给的行数据,把c字段的值加1,得到新的行数据,再调用引擎接口写入这行新数据。
    • 引擎将这行新数据更新到内存中,并同时写入redo log,此时redo log处于prepare状态,然后告知执行器执行完成了,随时可以提交。
    • 执行器生成这个操作的binlog,并把binlog写入磁盘。
    • 执行器调用引擎的提交事务接口,引擎把刚刚写入的redo log改为commit状态,更新完成。
    • 图片来自Mysql45讲02,深色代表Server层,浅色代表InnoDB。
      在这里插入图片描述

    两阶段提交

    • 为什么必须有两阶段提交?是为了让两份日志之间逻辑一致。
    • binlog会记录所有逻辑操作,恢复数据时可以采用A时间点全量数据+A时间点后binlog的方式。
    • redo log 和 binlog 都可以用于表示事务的提交状态,而两阶段提交就是让这两个状态保持逻辑上的一致。

    配置

    • innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到磁盘,这样可以保证 MySQL 异常重启之后数据不丢失。
    • sync_binlog 这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘,这样可以保证 MySQL 异常重启之后 binlog 不丢失。
    展开全文
  • 在实际开发过程中,有时我们很有可能需要某个表的操作痕迹,或通过记录的SQL... 据说Oracle8i之后,就提供了Logminer日志分析工具,虽然没有GUI图形化的界面,但也阻挡不了使用他的决心。 Oracle11g下使用的情况:...

               在实际开发过程中,有时我们很有可能需要某个表的操作痕迹,或通过记录的SQL语句进行有目的性的数据恢复(此时POINT-IN-TIME恢复已经满足不了更细的粒度)、或仅仅是查看;

               据说Oracle8i之后,就提供了Logminer日志分析工具,虽然没有GUI图形化的界面,但也阻挡不了使用他的决心。

               Oracle11g下使用的情况:

     

               (1)、数据库开启归档模式

               在安装Logminer之前,我们先讲数据库设置为归档模式:

              注意:如果开启日志分析功能,仅仅是分析系统默认的Redo01.log、Redo02.log、Redo03.log是不够的,因为重做日志是循环填充的方式,下一个循环周期开启就是丢失上一个周期的日志信息,势必需要将重做日志进行归档保存。

               windows下利用cmd下sqlplus命令登录oracle,并查看归档模式,如果未归档,需要在mount状态下,开启归档模式,最好打开数据库:

     1 //cmd下连接数据库
     2 C:\Users\Administrator>sqlplus sys/123456@orcl as sysdba
     3 
     4 //连接成功后,查看归档模式
     5 SQL> archive log list;
     6 Database log mode              No Archive Mode //非归档模式
     7 ...
    
     9 //关闭数据库
    10 SQL> shutdown immediate;
    11 ...
    
    13 //以mount状态启动数据库
    14 SQL> startup mount;
    15 ...
    16 SQL> alter database archivelog;//启动归档模式 17 Database altered. 19 SQL> archive log list; 20 Database log mode Archive Mode //此时已是归档模式 22 //打开数据库 23 SQL> alter database open;

     

              (2)、安装Logminer

     

               首先,需要确定您安装的oracle版本的数据库是否具备Logminer,在安装目录下查看,即$ORACLE_HOME/rdbms/admin下是否有dbmslm.sql、dbmslmd.sql,我安装目录下的两个文件:

    1 D:\app\admin\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslm.sql
    2 D:\app\admin\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslmd.sql

              执行安装命令(使用具有dba的权限来执行安装,可以用sys用户登录,然后执行SQL>grant dba to SCOTT;,这样scott用户就具有dab的权限)

             

           安装成功后,可以在PL/SQL Developer 的左边对象Objects导航中的Packages包下会找到DBMS_LOGMNR、DBMS_LOGMNR_D包,其中:

          DBMS_LOGMNR:用来分析日志文件

          DBMS_LOGMNR_D:用来创建数据字典文件

             

         (3)、创建数据字典文件

          数据字典文件中会包括数据库的DB_ID,以及编码格式,如果不创建数据字典文件,默认解析的日志信息均以16进制编码格式进行展示,无法直观理解,下面我们使用命令创建数据字典文件:

           需要创建数据字典目录和数据字典文件

          首先,创建数据字典目录

    CREATE DIRECTORY utlfile AS 'D:\app\admin\oradata\orcl\LOGMNR';
    
    alter system set utl_file_dir='D:\\app\admin\oradata\orcl\LOGMNR' scope=spfile;  

        同时,开启附加日志模式,关于附加日志supplemental log的解释:可以指示数据库在日志中添加额外信息到日志流中,以支持基于日志的工具,如逻辑standby、streams、GoldenGate、LogMiner。

    alter database add supplemental log data;

       进行到此时,需要重启下数据库,因为在添加字段目录的时候,我们使用的是'scope=spfile',即下次启动时生效。

    //关闭数据库
    SHUTDOWN IMMEDIATE;
    
    //启动数据库
    STARTUP;

      如果想验证数据字典是否设置成功,可以在命令行输入以下命令,查看:(出现下面截图所示可表示设置目录成功)

    SHOW PARAMETER utl_file_dir;

       创建好目录后,继续使用具有dba权限的SCOOT用户,创建数据字典文件:

    EXECUTE dbms_logmnr_d.build(dictionary_filename => 'dictionary.ora', dictionary_location =>'D:\app\admin\oradata\orcl\LOGMNR');

      

          (4)、分析日志文件

         SCOTT用户下,对数据进行一些操作

    -- 创建简单表
    create table WY_TEST(ID NUMBER(10,0),USERNAME VARCHAR2(10)); 
    
    SELECT * FROM WY_TEST; -- 此时查询内容为空
    
    -- 插入两条数据
    INSERT INTO WY_TEST(ID,USERNAME) VALUES(1,'WY01');
    INSERT INTO WY_TEST(ID,USERNAME) VALUES(2,'WY02');
    COMMIT;
    
    SELECT * FROM WY_TEST; -- 查询验证插入是否成功
    
    -- 修改内容
    UPDATE WY_TEST SET USERNAME='WY03' WHERE ID=2;
    COMMIT;
    
    SELECT * FROM WY_TEST; -- 查询验证修改是否成功
    
    --删除内容
    DELETE FROM WY_TEST WHERE ID=2;
    COMMIT;
    
    SELECT * FROM WY_TEST; -- 此时表中内容:ID=1,USERNAME='WY01'

     据介绍,当表数据发生变化后,需要重新创建数据字典文件,所以,此时,我们需要重新执行下创建数据文件的语句:

    EXECUTE dbms_logmnr_d.build(dictionary_filename => 'dictionary.ora', dictionary_location =>'D:\app\admin\oradata\orcl\LOGMNR');

     此时,开始加载日志文件进行分析,您可以加载当前正在使用的日志文件,也可以像我这样,把三个重做日志文件均加载进去;

    SQL> begin
     2  dbms_logmnr.add_logfile(LogFileName=>'D:\app\admin\oradata\orcl\REDO01.LOG',Options=>dbms_logmnr.NEW);
     3  END;
     4  /
    
    SQL> BEGIN
     2  dbms_logmnr.add_logfile(LogFileName=>'D:\app\admin\oradata\orcl\REDO02.LOG',Options=>dbms_logmnr.ADDFILE);
     3  dbms_logmnr.add_logfile(LogFileName=>'D:\app\admin\oradata\orcl\REDO03.LOG',Options=>dbms_logmnr.ADDFILE);
     4  END;
     5  /

     

       接下来,使用Logminer对日志文件进行分析

    SQL> Execute dbms_logmnr.start_logmnr(DictFileName=>'D:\app\admin\oradata\orcl\LOGMNR\dictionary.ora');

       执行命令成功后,我们可以在v$logmnr_contents视图中进行查看到操作的日志内容

    SQL> SELECT sql_redo, sql_undo from v$logmnr_contents where seg_name='WY_TEST';

     从截图中,可以看到所有执行的痕迹,以及撤销此步骤的UNDO SQL,从这点看出,日志分析还是非常有用的。

     

     上面提到过,如果可以‘分析’当前正在使用的Redo Log,通过下面的语句查询

    SELECT GROUP#,SequencE#,status,first_change# from v$LOG ORDER BY FIRST_CHANGE#;

       从运行的截图中可以看到,当前使用的是Redo03.Log,所以在上面使用Logminer进行分析的时候,仅需要加载Redo03.Log日志文件进行分析即可

     

       (5)、分析归档日志文件

     

       我们知道,只有到Redo Log写满后进行自动切换时,如果数据库开启归档模式,会将已满的Redo Log写入到归档日志中,我们也可以手动进行切换(通常,多执行几次)

    ALTER SYSTEM SWITCH LOGFILE;

     

       我们执行后,会发现,flash_recovery_area目录下会出现orcl\ArchiveLog目录(没有设置归档的目录,默认是在flash_recovery_area下面)

       注:可以通过以下方式,查询到归档日志目录

    select sequence#, FIRST_CHANGE#, NEXT_CHANGE#,name from v$archived_log order by sequence# desc

     

       此时,我只要选择将最新的归档日志进行分析,即可

    SQL> begin
      2  dbms_logmnr.add_logfile(LogFileName=>'D:\app\admin\flash_recovery_area\orcl\ARCHIVELOG\2017_08_19\O1_MF_1_18_DSH8OJF9_.ARC',options=>dbms_logmnr.new);
      3  end;
      4  /

       从截图中可以看到,执行的效果和分析Redo Log的结果相同

        

       欢迎大家补充指导,共同学习!

    转载于:https://www.cnblogs.com/wangyong/p/7396080.html

    展开全文
  • 这就需要依赖MySQL的redo logbinlog这两个重要的日志模块了,接下来分别说明这两个模块的作用。 重做日志 redo log MySQL在做数据更新操作时,如果每次都需要写进磁盘的话,那么需要到磁盘中找到对应的那条记录,...

    前言

    在MySQL数据库的使用中,肯定会遇到需要数据恢复到之前的某一时刻的需求,也会遇到数据库异常重启的情况,MySQL都是怎么解决这些问题的呢?

    这就需要依赖MySQL的redo log和binlog这两个重要的日志模块了,接下来分别说明这两个模块的作用。

    重做日志 redo log

    MySQL在做数据更新操作时,如果每次都需要写进磁盘的话,那么需要到磁盘中找到对应的那条记录,然后更新,这样下来,IO成本和查找成本都很高。为了解决这个问题,MySQL用到了WAL(Write-Ahead Logging)技术,它的关键点在于先写日志,再写磁盘,这就用到了redo log。

    具体的来说,当有一条记录需要更新的时候,InnoDB引擎先会把记录写到redo log里面,并更新内存,这个时候更新就算完成了。等到系统比较空闲的时候,InnoDB引擎会把这个记录更新到磁盘中。

    InnoDB的redo log是固定大小的,可以配置为一组4个文件,每个文件1GB大小,那么总共就可以记录4GB的操作,当写满的时候,会淘汰掉当前最老的记录以得到空闲空间。

    redo log是InnoDB引擎特有的日志,可以保证即使数据库发生异常重启,之前提交过的记录也不会丢失,这个能力称为crash-safe

    归档日志 binlog

    redo log是InnoDB引擎特有的日志,所以它属于引擎层,而Server层也有自己的日志,称为归档日志 binlog。

    binlog会记录所有的逻辑操作,并且是采用追加写的形式。主要用于数据库恢复到某一个时刻,当然这样的前提是有这段时间的binlog。

    两者区别

    1. redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。
    2. redo log是物理日志,记录在某个数据页做了什么修改;binlog是逻辑日志,记录这个语句的原始逻辑。
    3. redo log是循环写,空间固定会用完;binlog是可以追加写入的,并不会覆盖以前的日志。
    展开全文
  • 在了解binlog和redo log之前先来了解一下MySQL数据的基础架构,知道了 MySQL 由那些组件组成?以及这些组件的作用是什么? Mysql基本架构概览 简单来说 MySQL 主要分为 Server 层和存储引擎层: Server 层:...

     

     MySQL基础架构分析

    在了解binlog和redo log之前先来了解一下MySQL数据的基础架构,知道了 MySQL 由那些组件组成?以及这些组件的作用是什么?

    Mysql基本架构概览

    简单来说 MySQL 主要分为 Server 层和存储引擎层:

    • Server 层:主要包括连接器、查询缓存、分析器、优化器、执行器等,所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图,函数等,还有一个通用的日志模块 binglog 日志模块。
    • 存储引擎: 主要负责数据的存储和读取,采用可以替换的插件式架构,支持 InnoDB、MyISAM、Memory 等多个存储引擎,其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了。

    service层基本组件介绍

    • 连接器: 身份认证和权限相关。主要负责用户登录数据库,进行用户的身份认证,包括校验账户密码,权限等操作。
    • 查询缓存: 执行查询语句的时候,会先查询缓存(MySQL 8.0 版本后移除,因为这个功能不太实用)。主要用来缓存我们所执行的 SELECT 语句以及该语句的结果集。
    • 分析器: 没有命中缓存的话,SQL 语句就会经过分析器,分析器说白了就是要先看你的 SQL 语句要干嘛,再检查你的 SQL 语句语法是否正确。分析器内也分为:词法分析和语法分析。词法分析简单来讲就是一条 SQL 语句由多个字符串组成,词法分析器要提取关键字,比如 select,提出查询的表,提出字段名,提出查询条件等等。做完这些操作后,就会进入语法分析。语法分析主要就是判断你输入的 sql 是否正确,是否符合 MySQL 的语法。
    • 优化器: 按照 MySQL 认为最优的方案去执行。比如多个索引的时候该如何选择索引,多表查询的时候如何选择关联顺序等。
    • 执行器: 执行语句,然后从存储引擎返回数据。当选择了执行方案后,MySQL 就准备开始执行了,首先执行前会校验该用户有没有权限,如果没有权限,就会返回错误信息,如果有权限,就会去调用引擎的接口,返回接口执行的结果。

    二 语句分析

    了解完MySQL基础架构之后,那么我们的SQL语句到底是怎么执行的呢?在这里我们可以把SQL语句分为两类,一类是查询语句,另一类是更新语句(新增、更新和删除)。

    2.1查询语句分析

    select * from tb_student  A where A.age='18' and A.name=' 张三 ';

    我们分析一下这条SQL语句的执行过程:

    • 先检查该语句是否有权限,如果没有权限,直接返回错误信息,如果有权限,在 MySQL8.0 版本以前,会先查询缓存,以这条 sql 语句为 key 在内存中查询是否有结果,如果有直接拿到缓存并返回结果,如果没有,执行下一步。

    • 通过分析器进行词法分析,提取 sql 语句的关键元素,比如提取上面这个语句是查询 select,提取需要查询的表名为 tb_student,需要查询所有的列,查询条件是这个表的 id='1'。然后判断这个 sql 语句是否有语法错误,比如关键词是否正确等等,如果检查没问题就执行下一步。

    • 接下来就是优化器进行确定执行方案,上面的 sql 语句,可以有两种执行方案:

    a.先查询学生表中姓名为“张三”的学生,然后判断是否年龄是 18。
    b.先找出学生中年龄 18 岁的学生,然后再查询姓名为“张三”的学生。

    优化器会根据自己的优化算法进行选择执行效率最好的一个方案(优化器认为,有时候不一定最好)。确定完了执行计划后就准备开始执行了。

    • 进行权限校验,如果没有权限就会返回错误信息,如果有权限就会调用数据库引擎接口,返回引擎的执行结果。

    2.2更新语句分析

    以上就是一条查询 sql 的执行流程,那么接下来我们看看一条更新语句如何执行的呢?sql 语句如下:

    update tb_student A set A.age='19' where A.name=' 张三 ';

    这条语句也基本上会沿着上一个查询的流程走,只不过执行更新操作的时候需要将其记录到日志中,这就会引入日志模块了。MySQL 自带的日志模块式 binlog(归档日志) ,所有的存储引擎都可以使用。InnoDB 引擎还自带了一个日志模块 redo log(重做日志),我们就以 InnoDB 模式下来探讨这个语句的执行流程。流程如下:

    • 先查询到张三这一条数据,如果有缓存,也是会用到缓存。
    • 然后拿到查询的语句,把 age 改为 19,然后调用引擎 API 接口,写入这一行数据,InnoDB 引擎把数据保存在内存中,同时记录 redo log,此时 redo log 进入 prepare 状态,然后告诉执行器,执行完成了,随时可以提交。
    • 执行器收到通知后记录 binlog,然后调用引擎接口,提交 redo log 为提交状态。
    • 更新完成。

    这里肯定有同学会问,为什么要用两个日志模块,用一个日志模块不行吗?

    这是因为最开始 MySQL 并没与 InnoDB 引擎( InnoDB 引擎是其他公司以插件形式插入 MySQL 的) ,MySQL 自带的引擎是 MyISAM,但是我们知道 redo log 是 InnoDB 引擎特有的,其他存储引擎都没有,这就导致会没有 crash-safe 的能力(crash-safe 的能力即使数据库发生异常重启,之前提交的记录都不会丢失),binlog 日志只能用来归档。

    并不是说只用一个日志模块不可以,只是 InnoDB 引擎就是通过 redo log 来支持事务的。那么,又会有同学问,我用两个日志模块,但是不要这么复杂行不行,为什么 redo log 要引入 prepare 预提交状态?这里我们用反证法来说明下为什么要这么做?

    • 先写 redo log 直接提交,然后写 binlog,假设写完 redo log 后,机器挂了,binlog 日志没有被写入,那么机器重启后,这台机器会通过 redo log 恢复数据,但是这个时候 bingog 并没有记录该数据,后续进行机器备份的时候,就会丢失这一条数据,同时主从同步也会丢失这一条数据。
    • 先写 binlog,然后写 redo log,假设写完了 binlog,机器异常重启了,由于没有 redo log,本机是无法恢复这一条记录的,但是 binlog 又有记录,那么和上面同样的道理,就会产生数据不一致的情况。

    如果采用 redo log 两阶段提交的方式就不一样了,写完 binglog 后,然后再提交 redo log 就会防止出现上述的问题,从而保证了数据的一致性。那么问题来了,有没有一个极端的情况呢?假设 redo log 处于预提交状态,binglog 也已经写完了,这个时候发生了异常重启会怎么样呢? 这个就要依赖于 MySQL 的处理机制了,MySQL 的处理过程如下:

    • 判断 redo log 是否完整,如果判断是完整的,就立即提交。
    • 如果 redo log 只是预提交但不是 commit 状态,这个时候就会去判断 binlog 是否完整,如果完整就提交 redo log, 不完整就回滚事务。

    这样就解决了数据一致性的问题。

     

    三 redo log 和 binlog

    接下来我们详细的介绍redo log和binlog

    日志模块:redo log

    在 MySQL 中,如果每一次的更新操作都需要写进磁盘,然后磁盘也要找到对应的那条记录,然后再更新,整个过程 IO 成本、查找成本都很高。为了解决这个问题,MySQL 的设计者就采用了日志(redo log)来提升更新效率。

    而日志和磁盘配合的整个过程,其实就是 MySQL 里的 WAL 技术,WAL 的全称是 Write-Ahead Logging,它的关键点就是先写日志,再写磁盘。

    具体来说,当有一条记录需要更新的时候,InnoDB 引擎就会先把记录写到 redo log(redolog buffer)里面,并更新内存(buffer pool),这个时候更新就算完成了。同时,InnoDB 引擎会在适当的时候(如系统空闲时),将这个操作记录更新到磁盘里面(刷脏页)。

    redo log 是 InnoDB 存储引擎层的日志,又称重做日志文件,redo log 是循环写的,redo log 不是记录数据页更新之后的状态,而是记录这个页做了什么改动。

    redo log 是固定大小的,比如可以配置为一组 4 个文件,每个文件的大小是 1GB,那么日志总共就可以记录 4GB 的操作。从头开始写,写到末尾就又回到开头循环写,如下图所示。

    图中展示了一组 4 个文件的 redo log 日志,checkpoint 是当前要擦除的位置,擦除记录前需要先把对应的数据落盘(更新内存页,等待刷脏页)。write pos 到 checkpoint 之间的部分可以用来记录新的操作,如果 write pos 和 checkpoint 相遇,说明 redolog 已满,这个时候数据库停止进行数据库更新语句的执行,转而进行 redo log 日志同步到磁盘中。checkpoint 到 write pos 之间的部分等待落盘(先更新内存页,然后等待刷脏页)。

    有了 redo log 日志,那么在数据库进行异常重启的时候,可以根据 redo log 日志进行恢复,也就达到了 crash-safe。

    redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到磁盘。这个参数建议设置成 1,这样可以保证 MySQL 异常重启之后数据不丢失。

    日志模块:binlog

    MySQL 整体来看,其实就有两块:一块是 Server 层,它主要做的是 MySQL 功能层面的事情;还有一块是引擎层,负责存储相关的具体事宜。redo log 是 InnoDB 引擎特有的日志,而 Server 层也有自己的日志,称为 binlog(归档日志)。

    binlog 属于逻辑日志,是以二进制的形式记录的是这个语句的原始逻辑,依靠 binlog 是没有 crash-safe 能力的。

    binlog 有两种模式,statement 格式的话是记 sql 语句,row 格式会记录行的内容,记两条,更新前和更新后都有。

    sync_binlog 这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘。这个参数也建议设置成 1,这样可以保证 MySQL 异常重启之后 binlog 不丢失。

    为什么会有两份日志呢?

    因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM,但是 MyISAM 没有 crash-safe 的能力,binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件形式引入 MySQL 的,既然只依靠 binlog 是没有 crash-safe 能力的,所以 InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。

    redo log 和 binlog 区别:

    1. redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。
    2. redo log 是物理日志,记录的是在某个数据页上做了什么修改;binlog 是逻辑日志,记录的是这个语句的原始逻辑。
    3. redo log 是循环写的,空间固定会用完;binlog 是可以追加写入的。追加写是指 binlog 文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。

    参考链接:

    https://www.cnblogs.com/wupeixuan/p/11734501.html#1425468903

    https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485097&idx=1&sn=84c89da477b1338bdf3e9fcd65514ac1&chksm=cea24962f9d5c074d8d3ff1ab04ee8f0d6486e3d015cfd783503685986485c11738ccb542ba7&token=79317275&lang=zh_CN#rd

    展开全文
  • WAL的全称是Write-Ahead Logging,它的关键点就是先写日志,再写磁盘。...redo log是InnoDB引擎特有的日志,而Server层也有自己的日志,称为binlog(归档日志)。 我想你肯定会问,为什么会有两份日志呢?.
  • Redo log(重做日志) Bin log(归档日志) 当执行一条更新语句时,MySQL是如何执行的。 以 update user set name = ‘zs’ where id = ‘00001’; 为例 1、建立连接后,分析器识别了这是一条更新SQL语句,清空...
  • 每日一贴,今天的内容关键字为归档拷贝 LogMiner A utility that enables log files to be read, analyzed, and interpreted by means of SQL statements. archived redo log 每日一道理 悲观的人,先被自己...
  • 日志文件分为重做日志文件(redo log file)和归档日志文件(archive log file)。 SQL> select group#, status, member from v$logfile; GROUP# STATUS MEMBER---------- ------- ----------------------------...
  • 项目中要对Oracle的redo.log进行解析,实现数据同步,由于项目逻辑原因,需要开启归档日志和补充日志。 归档日志 我们对Markdown编辑器进行了一些功能拓展与语法支持,除了标准的Markdown编辑器功能,我们增加了如下...
  • 数据归档日志,记录了更新语句的原始逻辑 什么用 归档日志,没有提供 crash-safe 的能力 两者对比 区别 实现层面 bin log 是 Server 层的实现,不依赖于具体的存储引擎 redo log 由 InnoDB 实现,提供了 crash-safe...
  • MySQL日志redo logbinlog

    千次阅读 2021-02-15 14:02:24
    只要是接触过MySQL的程序员,那么或多或少都有听过redo log(重做日志)binlog(归档日志)。今天就来分享一下这两个日志的用处区别。 简单来说,redo log是InnoDB特有的日志,如果使用的是其他存储引擎,就没有...
  • LogMiner A utility that enables log files to be read, analyzed, and interpreted by means of SQL statements.   ...A copy of one of the filled members of an online redo log group m
  • Oracle的重作日志分为两种,在线(online)离线(offline)归档日志文件,我这里主要分析归档日志,在线日志原理一样。 6.1、查看日志组的状况 SQL> select GROUP# ,SEQUENCE# ,STATUS from v$log;  ...
  • Oracle LogMiner 是Oracle公司从产品8i以后提供的一个实际非常有用的分析工具,使用该工具可以轻松获得Oracle 在线/归档日志文件中的具体内容,特别是该工具可以分析出所有对于数据库操作的DMLDDL语句。...
  • 为什么需要redo log内存中数据修改后,不必立即更新到磁盘---效率由日志完成数据的保护目的---效率其他副产品数据恢复(备份集+归档日志)数据同步(DG,streams,goldengate)日志挖掘什么是Redo log重做日志包含所有...
  • Oracle-归档日志详解(运行模式、分类) 一、Oracle日志分类  分三大类: Alert log files--警报日志,Trace files--跟踪日志(用户进程)   redo log 重做日志(记录数据库的更改)。  本文主要关注Oracle的...
  • 一.Oracle11gRac集群下Redo日志操作 关于联机重做日志文件组的删除需要注意以下几点: ①日志组为activecurrent状态时不可以删除 ②日志组在数据库级别删除后操作系统上的文件不会被级链删除 ③对于一个Oracle...
  • 在线日志和归档日志对于同步的影响 1、什么是在线日志(redo log) 在线日志即数据库目前正在使用的日志组,它属于一组日志文件,不同的数据库对日志组的设置功能有所不同 有的是几个日志文件,有的每组日志有可以...
  • 三、bin log (归档日志) 3.1 bin log有什么用 3.2 两阶段提交 3.3 为什么需要两阶段提交 小结 一、mysql大概架构 大体来说,mysql可以分为Server层存储引擎两部分。 Server 层包括连接器、查询缓存、...
  • 数据归档日志,记录了更新语句的原始逻辑 什么用 归档日志,没有提供 crash-safe 的能力 两者对比 区别 实现层面 bin log 是 Server 层的实现,不依赖于具体的存储引擎 redo log 由 InnoDB 实现,提供了 crash-safe...
  • 数据库归档日志

    千次阅读 2019-10-22 17:13:33
    关于归档日志:Oracle要将填满的在线日志文件组归档时,则要建立归档日志(archived redo log)。 其对数据库备份恢复有下列用处: 数据库后备以及在线和归档日志文件,在操作系统磁盘故障中可保证全部提交的事物可...
  • 重做日志文件和归档日志文件

    千次阅读 2017-02-13 21:53:30
    日志文件分为重做日志文件(redo log file)和归档日志文件(archive log file)。SQL> select group#, status, member from v$logfile;GROUP# STATUS MEMBER ---------- ------- ---------------------------------...
  • 重做日志redo log)

    2019-01-16 16:20:39
    重做日志可分为在线重做日志/联机重做日志(online redo log) 归档重做日志。 一、重做日志的功能 重做日志中所记载的数据称为重做记录(redo record),是它使数据库具备了恢复的能力。 二、在线重做日志 是重做...
  • 【关键术语】Redo log file 重做日志文件Archive log file 归档日志文件SCN(system change number)系统改变号 Checkpoint 检查点Log switch 日志切换 Redo entry 重做条目Log sequence number 日志序列号 Log file ...
  • 其实也是需要走上面的流程的(查询缓存这一步没有,上章有提到,在做更新操作时候,会清空查询缓存),只不过更新语句除了上面流程还会涉及到两个重要的日志模块redo log(重做日志) binlog(归档日志) ...
  • 不同点: MySQL 整体来看,其实就有两块:一块是 Server 层,它主要...而 Server 层也有自己的日志,称为 binlog(归档日志)。 (1)redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 520
精华内容 208
关键字:

归档日志和redo日志