精华内容
下载资源
问答
  • 如何开关数据库告警日志及修改日志级别
    千次阅读
    2021-11-17 14:34:34

    目录
    文档用途
    详细信息

    文档用途
    本文旨在介绍如何开启和关闭数据库告警日志及修改日志级别。

    详细信息
    先提供一份通用告警日志参数设置:

    打开数据库参数文件$PGDATA/postgresql.auto.conf,在文件末尾追加如下内容:

    logging_collector = on

    log_destination = ‘csvlog’

    log_directory = ‘hgdb_log’

    log_filename = ‘highgodb_%d.log’

    log_rotation_age = ‘1d’

    log_rotation_size = 0

    log_truncate_on_rotation = on

    log_min_messages = ‘WARNING’

    log_statement = ‘ddl’

    然后重启数据库(确保非业务时段执行)。

    pg_ctl restart

    这样配置后,将会达到如下配置目标:

    1.开启数据库告警日志记录;

    2.产生的日志文件位于data目录下的hgdb_log中;

    3.日志文件格式为csv;

    4.文件名以highgodb为前缀;

    5.日志大小无上限,按日保留,循环覆盖;

    6.消息级别在warning及以上的进行记录,sql语句在error级别及以上的被记录;

    7.所有ddl语句被记录。

    一.开启和关闭数据库告警日志的方法

    1.查询数据库告警日志是否开启

    连接数据库执行show logging_collector;

    返回结果是on则代表开启。off代表关闭。

    2.开启数据库告警日志方法

    打开数据库参数文件$PGDATA/postgresql.auto.conf,在文件末尾追加如下内容:

    logging_collector = on

    log_directory = ‘hgdb_log’

    然后重启数据库(确保非业务时段执行)。

    pg_ctl restart

    3.关闭数据库告警日志方法

    打开数据库参数文件$PGDATA/postgresql.auto.conf,在文件末尾追加如下内容:

    logging_collector = off

    然后重启数据库(确保非业务时段执行)。

    pg_ctl restart

    二.修改告警日志级别

    1.查询告警日志级别

    连接数据库执行

    show log_min_messages;

    show log_statement;

    2.修改告警日志级别

    2.1 log_min_messages

    控制哪些消息级别被写入到服务器日志。有效值是DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、INFO、NOTICE、WARNING、ERROR、LOG、FATAL和 PANIC。每个级别都包括其后的所有级别。级别越靠后,被记录的消息越少。

    级别介绍:

    DEBUG1…DEBUG5:极端情况下提供连续的更详细的信息。

    INFO:提供用户隐式要求的信息,例如来自VACUUM VERBOSE的输出。

    NOTICE:提供可能对用户有用的信息,例如长标识符截断提示。

    WARNING:提供可能出现的问题的警告,例如在一个事务块外COMMIT。

    ERROR:报告一个导致当前命令中断的错误。

    LOG:报告管理员一般需要的信息,例如检查点活动。

    FATAL:报告一个导致当前会话中断的错误。

    PANIC:报告一个导致所有数据库会话中断的错误。

    2.2 log_statement

    控制哪些SQL语句被记录。有效值是none(off)、ddl、mod和all(所有语句)。ddl记录所有数据定义语句,例如CREATE、ALTER和 DROP语句。mod记录所有ddl语句,外加数据修改语句例如INSERT, UPDATE、DELETE、TRUNCATE, 和COPY FROM。all记录包括select在内的所有语句。

    更多相关内容
  • 方法二: 设置检查点,自动截断日志 一般情况下,SQL数据库的收缩并不能很大程度上减小数据库大小,其主要作用是收缩日志大小,应当定期进行此操作以免数据库日志过大 1、设置数据库模式为简单模式:打开SQL企业...
  • MYSQL5.7.17默认是安装在C盘下的(C:\ProgramData\MySQL\MySQL Server 5.7)而且安装时是不能改变安装路径的,这时候数据库的data数据文件就需要我们改变存储路径了,接下来我就给大家说一下如何操作: 一:关掉...

    MYSQL5.7.17默认是安装在C盘下的(C:\ProgramData\MySQL\MySQL Server 5.7)而且安装时是不能改变安装路径的,这时候数据库的data数据文件就需要我们改变存储路径了,接下来我就给大家说一下如何操作:

    一:关掉MYSQL服务

    二:进入到C:\ProgramData\MySQL\MySQL Server 5.7  路径下,找到  my.ini   文件打开,找到


     datadir=C:/ProgramData/MySQL/MySQL Server 5.7\Data   

     这里就是MYSQL 数据库的路径  

    下面那一行就是要改变的存储路径

    三:在D盘下新建mySQLData文件夹如上图所示,把上面那一行默认的注释掉就好了

    四:把C:/ProgramData/MySQL/MySQL Server 5.7\Data  下的所有文件拷到mySQLData文件夹下

    五:重启MYSQL服务

    六: 日志文件查询路径

    查找错误日志文件路径
    show variables like ‘log_error’;


    查找日志文件路径
    show variables like ‘general_log_file’;


    慢查询日志文件路径
    show variables like ‘slow_query_log_file’;

    命令行参数

    –log-bin=filename:记录二进制日志文件的位置,尽量指定路径名,如果e68a84e799bee5baa6e997aee7ad9431333335346133不指定的话则保存在数据目录;

    –log-bin-index=file:记录二进制日志文件索引的位置,保存了日志文件名;

    –max_binlog_size:单个文件最大多少;

    –binlog-do-db=db_name:哪个数据库使用,只有这个数据库使用;

    –binlog-ignore-db=db_name:哪个数据库不使用,只有这个数据库不使用;

    系统变量

    log_bin:日志的位置;

    binlog_cache_size:二进制日志缓存大小,是每一个连接进来的线程分配的大小,不是整个服务器的大小;

    max_binlog_cache_size:最大缓存大小;

    max_binlog_size:单个文件最大大小,超过此大小则再分配一个文件,但是一个事务必须在一个文件中,所以可能会稍大点;

    binlog_cache_use:当前连接使用的binlog缓存的事务的数量,使用show status like ‘binlog_cache_use’查看(show status命令显示了所有连接到mysql服务器的状态值);

    binlog_cache_disk_use:如果binlog_cache_use不够用,则在磁盘上缓存,应该尽量避免;

    binlog_do_db:设置master-slave时使用;

    binlog-ignore-db:设置哪个数据库不记录日志;

    sync_binlog:缓存与硬盘的同步频率(commit多少下同步一次,0表示服务器自动控制);

     

     

     

    展开全文
  • MYSQL数据库日志

    千次阅读 2020-08-29 11:11:20
    Mysql数据库日志 4 .日志讲解 一、innodb引擎中的redo/undo log是什么 二、什么是binlog 三、binlog的三种模式 5. 日志原理 事务的原语操作 延迟的数据库修改redo 立即的数据库修改undo + redo 缓冲区管理 ...

     

    目录

    1.日志介绍

    2. 日志作用

    3. 日志分类

    Mysql数据库日志

    4 .日志讲解

    一、innodb引擎中的redo/undo log是什么

    二、什么是binlog

    三、binlog的三种模式

    5. 日志原理

    事务的原语操作

    延迟的数据库修改redo

    立即的数据库修改undo + redo

    缓冲区管理

    日志缓冲

    数据库缓冲

    操作系统在缓冲区管理的作用

    检查点

    静态检查点

    动态检查点

    对比

    6 日志应用


    1.日志介绍

    数据库都具有事务日志,用于记录所有事务以及每个事务对数据库所做的修改。事务日志是数据库的重要组件,如果系统出现故障,则可能需要使用事务日志将数据库恢复到一致状态。删除或移动事务日志以前,必须完全了解此操作带来的后果。
    事务日志支持以下操作:

        恢复个别的事务。
        在 SQL Server 启动时恢复所有未完成的事务。
        将还原的数据库、文件、文件组或页前滚至故障点。
        支持事务复制
        支持备份服务器解决方案。

    那时有两个痛点:1,某个用户电脑忽然断电,数据写入不完整,导致大家都不能用了;2、多个用户对同一条记录进行写操作,或读与写不致,或ID增量重号。

    现在的数据库系统(Oracel、DB2、MS sql、Mysql等)都支持多用户,所有的数据库系统(包括Exchange),都是把数据先写到日志中,等某个时机(比如:确认commit)后再写到数据库记录中,日志是数据库最重要的数据之一,理解日志是相当重要的。为什么要用日志呢?就是要解决Foxfro多用户的痛点一啊。
    日志一般分成Undo与Redo:Undo一般用于事务的取消与回滚,记录的是数据被修改前的值,Redo一般用于恢复已确认但未写入数据库的数据,记录的是数据修改后的值,例如:数据库忽然断电重启,数据库启动时一般要做一致性检查,会把已写到Redo的数据但未写入数据库的数据重做一遍。

    数据库系统如何来确认哪些数据需要redo或undo呢?那就需要一个检查点(checkpoint),在系统中一般有一个表或一个控制文件来记录检查点,日志是按顺序一直写下去的,检查点设置后,只需要比对检查点之后的数据就可以了。

    2. 日志作用

    修改数据库时候,客户端发送一个update命令,数据库服务器收到update请求,数据库引擎首先会把表里面的数据先按照8页一个盘区的方式读到缓存里面,读入缓冲区后,就要在硬盘的日志文件中记录数据修改的操作过程以及原始参数,然后根据客户端的要求修改缓冲区中的数据,最后检查点程序向数据库中写入已经提交的事务(一次或者多次数据的修改,也就是批处理数据的修改,这样减少写盘的次数,提高效率)。如果内存里面的数据经过了修改,但是没有写入磁盘,也就是没有和磁盘里面的数据同步,这就是脏数据了。

    当你的数据在内存当中但是还没有写入硬盘的数据库中的时候,突然断电了,假如这时候有个银行帐户的转帐,如果发生这种事情的话,银行系统一般如何处理这种情况呢?以前是通过填写单子的方式来保证避免这种问题,现在都是通过日志来保证的,因为先是写入日志,然后才在内存中修改数据,日志中有个叫做检查点的东西,这个checkpoint后面的数据为脏数据块,证明没有写入硬盘,下一次启动系统后,会检查日志中的脏数据块记录,然后把他们再重新作一遍。

    Oracle中用的是还原模式,不是归档模式,如果执行delete from删除的话,如果是完全还原模式的话,删除的所有数据都必须记录日志,sqlserver中全表的删除是不写日志的,这是简单的还原模式,无法还原了。

    3. 日志分类

    数据库日志主要分为普通日志、重点日志两种类型

    Mysql数据库日志

    MySql日志类型解析说明
    错误日志(error log)当数据库启动、运行、停止时产生该日志
    普通查询日志(general query log)客户端连接数据库执行语句时产生该日志
    二进制日志(binary log)当数据库内容发生改变时产生该日志,也被用来实现主从复制功能
    中继日志(relay log)从库上收到主库的数据更新时产生该日志
    慢查询日志(show query log)SQL语句在数据库查询超过指定时间时产生该日志
    DDL日志(metadata log)执行DDL语句操作元数据时产生该日志

    4 .日志讲解

    一、innodb引擎中的redo/undo log是什么

    • redo
      介绍redo 日志是什么时,需要先回顾一下操作数据库数据的逻辑,一般是这样:首先,从数据库文件中找到记录,文件一般是按照一种特定的格式存放,比如页,然后加载整页数据到内存,在内存中进行数据的操作(脏页)然后将脏页同步回文件,一般不会立即将脏页刷回到磁盘,这样会产生大量的随机IO操作,性能低下,如果不立即刷回磁盘,那么当服务器挂掉后,存放在内存中的数据会丢失,造成数据的不一致性,也就无从持久化。为了解决这一矛盾,引入了redo日志。

    • undo
      undo日志是取消操作,用于事务回滚,将数据恢复到修改之前的状态,InnoDB的多版本并发控制(MVCC)就是基于undo来实现的 (原子性)

    小结:redo与undo是MySQL存储引擎级别的日志,俗称事务日志,与事务的实现息息相关

    二、什么是binlog

    数据库的任何变化(创建表,更新数据库,对行数据进行增删改),都以二进制文件的方式记录在主库的Binary Log(即binlog)日志文件中,(对于select操作则不会被记录到binlog里,因为它并没有修改数据库的数据),binlog是在事务最终commit前写入的,在MySQL主从复制中就是依靠binlog来实现。

    三、binlog的三种模式

    • row:
      基于行的模式,记录的是行的变化,很安全。但是binlog会比其他两种模式大很多,在一些大表中清除大量数据时在binlog中会生成很多条语句,可能导致从库延迟变大。
    • statement:
      基于SQL语句的模式,某些语句和函数如UUID, LOAD DATA INFILE等在复制过程可能导致数据不一致甚至出错。
    • mixed:
      混合模式,根据语句来选用是statement还是row模式。

    5. 日志原理

    事务的原语操作

    在事务系统的运行当中,有三个地址空间供元素存储:

    • 磁盘空间
    • 缓冲区
    • 事务的局部地址空间。

    一个简单的读、修改X元素操作的流程如:事务到缓冲中读取元素X,如果命中,则读取事务局部地址空间并返回,如果未命中,则先将相关页从磁盘读入缓冲区。事务在它的局部地址空间中修改元素X,然后写入缓冲区,再从缓冲区写入磁盘。当然缓冲区的数据也可能不是立即拷贝入磁盘的,这取决于具体的缓冲区管理策略。
    为了便于描述,我们描述了4个操作原语:

    • INPUT(X):将包含数据库元素X的磁盘块拷贝到内存缓冲区
    • READ(X,t):将数据库元素X拷贝到事务的局部变量t。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。接着将X的值赋给局部变量t。
    • WRITE(X,t):将局部变量t的值拷贝到内存缓冲区中的数据库元素X。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。将着将t的值拷贝到缓冲区中的X。
    • OUTPUT(X):将包含X的缓冲区拷贝到回磁盘。

    日志记录

    • <Ti start>
    • <Ti, Xj, V1, V2>
    • <Ti commit>
    • <Ti abort>

    日志必须放在稳定存储器上(99.999%不会丢失)

    延迟的数据库修改redo

    • 日志仅需记录数据项的新值

    • 所有日志(包含commit)写到稳定缓存器后,再执行真正的更新write操作缩短日志记录的时间

    • 恢复时redo同时包含 <Ti start><Ti commit> 的事务

    立即的数据库修改undo + redo

    • 允许在事务仍处于活跃时,就输出到数据库

    • 日志需记录数据项的原始值与新值

    • Ti执行任何write操作前,先写日志

    • 与数据项B相关的日志写到稳定缓存器后,才执行output(B)操作

    • 恢复时同时采用redo与undo机制
      1.redo同时包含 <Ti start><Ti commit> 的事务(可能已提交事务尚未执行output操作
      2.undo只包含 <Ti start> 的事务

    缓冲区管理

    日志缓冲

    遵循先写日志规则。
    日志只允许以附加的方式写入数据。日志块最初在主存中创建,像数据块一样也由缓冲区管理,在确当的时刻,日志块会从缓冲区写入到磁盘。
    

    数据库缓冲

    虚拟内存换页的时候,会(由操作系统)输出块B1,在B1输出前,应当先输出与块B1相关的日志记录到稳定存储器
    

    操作系统在缓冲区管理的作用

    方法一:数据库保留部分主存为缓冲区,对其管理,而不是让操作系统管理(然而几乎所有操作系统都完全控制主存区)
    方法二:在操作系统的虚拟内存中实现缓冲区,会导致输出两次,一是在操作系统换页时,一是在数据库系统进行
    

    检查点

    静态检查点

    1. 停止接受新的事务
    2. 等待所有当前的活动事务提交或终止,并且在日志文件中写COMMIT或ABORT记录。
    3. 将日志刷新到磁盘
    4. 写入日志记录<CKRT>,并再次刷新记录。
    5. 重新开始接受新事务。
      当恢复时,扫描到<CKRT>日志时,就不需要继续扫描日志记录了。

    动态检查点

    静态检查点的缺点在与,可能需要很长时间等待活跃事务的完成,在用户系统看来似乎是静止了。非静态检查克服了该缺点,在做检查点时允许新事务进入。步骤如下:
    1) 写入日志记录<START CKPT(T1,……,Tk)>.其中T1,……,Tk为活跃事务。
    2) 等待T1,……,Tk每一个事务提交或终止,但允许其它事务开始。
    3) 当T1,……,Tk都已完成时,写入日志记录<END CKPT>并刷新日志。

    当系统发生故障时,从日志尾部开始扫描日志。根据扫描过程中先遇到<END CKPT>记录还是<START CKPT(T1,……,Tk)>记录,有两种情况。

    1) 如果先遇到<END CKPT>记录。所有未完成的事务在<START CKPT(T1,……,Tk)>记录后开始,只要扫描到<START CKPT(T1,……,Tk)>就不需要继续扫描了。<START CKPT(T1,……,Tk)>前的记录是可以截断的。

    2) 如果先遇到<START CKPT(T1,……,Tk)>,那么崩溃发生在检查点过程中。未完成事务只可能是到达<START CKPT(T1,……,Tk)>前遇到的那些,以及T1,……,Tk在崩溃前未完成的那些。因此只要继续扫描到未完成事务中最早的那个事务的开始就行了。
    一个通常的规律是,一旦<END CKPT>记录到了磁盘,我们就可以将上一个<START CKPT>记录前的日志删除了。

    对比

    都是先output日志再output数据库元素
    undo:每write一条日志,write一次数据项更新,日志记录旧值,
    redo:write完所有日志,再延迟更新write数据项,日志记录新值

    6 日志应用

    一:事务系统

      1.事务的工作模型

      事务必须满足原子性,所封装的操作或者全做或者全不做。

      事务管理系统需要做两件事,1)让日志系统产生日志,2)保证多个事务并发执行,满足ACID特性。

        事务管理管理器控制查询处理器的执行、控制日志系统以及缓冲区。日志在缓冲区生成,日志管理器在一定的时候控制缓冲区的刷盘操作。当系统崩溃的时候,恢复管理器就被激活,检查日志并在必要时利用日志恢复数据。

      2.事务的原语操作

      在事务系统的运行当中,有三个地址空间供元素存储:1)磁盘空间、2)缓冲区、3)事务的局部地址空间。

      一个简单的读、修改X元素操作的流程如:事务到缓冲中读取元素X,如果命中,则读取事务局部地址空间并返回,如果未命中,则先将相关页从磁盘读入缓冲区。事务在它的局部地址空间中修改元素X,然后写入缓冲区,再从缓冲区写入磁盘。当然缓冲区的数据也可能不是立即拷贝入磁盘的,这取决于具体的缓冲区管理策略。

      为了便于描述,我们描述了五个操作原语:

      1) INPUT(X):将包含数据库元素X的磁盘块拷贝到内存缓冲区

      2) READ(X,t):将数据库元素X拷贝到事务的局部变量t。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。接着将X的值赋给局部变量t。

      3) WRITE(X,t):将局部变量t的值拷贝到内存缓冲区中的数据库元素X。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。将着将t的值拷贝到缓冲区中的X。

      4) OUTPUT(X):将包含X的缓冲区拷贝到回磁盘。

    3.应用

      假设银行系统数据库中有两个元素,元素A(表示用户1的余额,值为1000,单位:RMB)与元素B(表示用户2的余额,值为500,单位:RMB)。这时候用户1需要向用户2转帐50元。相应的过程为:

      A := A – 50;

      B := B + 50;

      执行之前,两个用户的总余额为1500(1000+500),两个操作执行成功之后总余额还是1500(950+550)。处于一致性状态。

      如果只有前一条执行成功,那总额只为1450(950+50)。处于不一致状态。

      为了避免这种不一致状态,我们需要将这两个操作封装成一个事务T。

      我们将这两个操作分解为原语操作。如下:

      READ(A,t); t := t-50; WRITE(A,t);

      READ(B,t); t := t+50; WRITE(B,t);

      OUTPUT(A); OUTPUT(B) //这两个OUTPUT原语操作由缓冲区管理器发出。

      表1给出了这8个原语操作的执行步骤,给出了每一步中A和B的内存值、磁盘拷贝的值以及事务T地址空间中局部变量t的值

    表1: 一个事务的步骤及其对内存和磁盘的影响

     

     

    步骤

     

    动作

     

    t

     

    内存A

     

    内存B

     

    磁盘A

     

    磁盘B

     

    1

     

    READ(A,t)

     

    1000

     

    1000

     

     

     

    1000

     

    500

     

    2

     

    t := t-50

     

    950

     

    1000

     

     

     

    1000

     

    500

     

    3

     

    WRITE(A,t)

     

    950

     

    950

     

     

     

    1000

     

    500

     

    4

     

    READ(B,t)

     

    500

     

    950

     

    500

     

    1000

     

    500

     

    5

     

    t := t+50

     

    550

     

    950

     

    500

     

    1000

     

    500

     

    6

     

    WRITE(B,t)

     

    550

     

    950

     

    550

     

    1000

     

    500

     

    7

     

    OUTPUT(A)

     

    550

     

    950

     

    550

     

    950

     

    500

     

    8

     

    OUTPUT(B)

     

    550

     

    950

     

    550

     

    950

     

    550

     

      在表1中不难发现,只要所有的这些步骤都执行成功,数据库的一致性就能得到保持。如果在执行OUTPUT(A)前系统发生了故障,那么磁盘上存储的数据库不会受到任何影响,就好象事务T从来没有发生过一样。但是如果故障在OUTPUT(A)后而在OUTPUT(B)前发生,那么数据就会处于不一致状态(从表中可以看出,磁盘中A为950,B为500)。我们不能防止这种情况的发生,但可以安排当这些情况发生时对问题进行修复-----或者A为1000、B为为500,或者A为950,B为550。

      二:undo日志

      1.概述

      日志是日志记录的一个序列。在多事务的数据库系统中,每个事务有若干个操作步骤。每个日志记录记载有关某个事务已做的某些情况。几个事务的行为可以是“交错的”,因此可能是一个事务的某个步骤被执行,并且其效果被记录到日志中,接着执行另外一个事务的某个步骤并记入日志,接着可能接着做第一事务的下一个步骤,也可能执行另外一个事务的某个步骤。依次类推。事务的交错执行使日志更复杂,因为仅在事务结束后记载事务的全过程是不够的。

     如果系统崩溃,恢复管理器就被激活,检查日志以重建数据库的一致性状态。恢复时,有些事务的工作将会重做,它们写到数据库的新值会重写一次。而另外一些事务的工作将被撤消,数据库被恢复,将仿佛这些事务从来没执行过一样。

      Undo日志是日志类型的一种,这类日志仅仅进行第二类修复。对于要被撤消的事务,因为不能肯定它对数据库的修改是否已经写到磁盘中,所以对于该事务的所有更新都将被撤消,数据库恢复到事务发生以前的状态。

      2.日志记录

      日志只允许以附加的方式写入数据。日志块最初在主存中创建,像数据块一样也由缓冲区管理,在确当的时刻,日志块会从缓冲区写入到磁盘。

      关于undo记录形式有四种:

      1) : 这一记录表示事务T开始

      2) : 事务T已经完成。

      3) : 事务T不能成功执行。

      4) : 事务T改变了数据库元素X的值,元素X原来的值为v。

      3.undo日志规则

      要想让undo日志能使我们从系统故障中恢复,事务必须遵循两条规则。

      规则1)如果事务T改变了数据库元素X,那么形如的日志记录必须在X的新值写到磁盘前写到磁盘

      规则 2)如果事务提交,则其COMMIT日志记录必须在事务改变的所有数据库元素已写到磁盘后再写到磁盘,但应尽快。

      简单概括,undo日志系统顺序如下:

      1) 指明所改变数据库元素的日志记录

      2) 改变的数据库元素自身

      3) COMMIT日志记录。

      4.应用

      对于前面所举的例子(A转帐50元给B帐号),如果使用了undo日志系统,则相关的工作流程如表2如下。

    表2:undo日志系统的工作原理

     

    步骤

     

    动作

     

    t

     

    内存A

     

    内存B

     

    磁盘A

     

    磁盘B

     

    undo日志

     

    1

     

     

     

     

     

     

     

     

     

     

     

     

     

    <START T>

     

    2

     

    READ(A,t)

     

    1000

     

    1000

     

     

     

    1000

     

    500

     

     

     

    3

     

    t := t-50

     

    950

     

    1000

     

     

     

    1000

     

    500

     

     

     

    4

     

    WRITE(A,t)

     

    950

     

    950

     

     

     

    1000

     

    500

     

    <T, A, 1000>

     

    5

     

    READ(B,t)

     

    500

     

    950

     

    500

     

    1000

     

    500

     

     

     

    6

     

    t := t+50

     

    550

     

    950

     

    500

     

    1000

     

    500

     

     

     

    7

     

    WRITE(B,t)

     

    550

     

    950

     

    550

     

    1000

     

    500

     

    <T, B, 500>

     

    8

     

    FLUSH LOG

     

     

     

     

     

     

     

     

     

     

     

     

     

    9

     

    OUTPUT(A)

     

    550

     

    950

     

    550

     

    950

     

    500

     

     

     

    10

     

    OUTPUT(B)

     

    550

     

    950

     

    550

     

    950

     

    550

     

     

     

    11

     

     

     

     

     

     

     

     

     

     

     

     

     

    <COMMIT T>

     

    12

     

    FLUSH LOG

     

     

     

     

     

     

     

     

     

     

     

     

     在表2,我们可以看到FLUSH LOG这个命令。该命令的用于强制将还没有刷盘日志记录写到磁盘上。对于步骤8执行之前,三个undo记录(,,)是存储在缓冲区中的(这样描述是为将问题简单化),执行步骤8之后,三条undo记录便写入了磁盘日志文件。在步骤12再次执行FLUSH LOG命令时,只将未刷盘的日志记录写入磁盘。

      步骤9、10,在前面已经描述过,是将数据库元素的修改从缓冲区写入到磁盘文件,因为WRITE操作仅仅是将修改反应到缓冲区中(这样描述也是为了将问题简单化)。 

     关注步骤8,执行完步骤8之后,将满足undo的规则1(如果事务T改变了数据库元素X,那么形如的日志记录必须在X的新值写到磁盘前写到磁盘)。在我们真正将数据库元素A与B的修改反应到磁盘前,我们已经将它们对应的与写入到磁盘日志文件。

      关注步骤11与步骤12,执行它们将满足undo的规则2(如果事务提交,则其COMMIT日志记录必须在事务改变的所有数据库元素已写到磁盘后再写到磁盘,但应尽快)。我们已经将数据库元素A与B的修改反应到磁盘上,接着可以写入来表示事务T的成功执行,但是该日志记录还在缓冲区中,所以我们在步骤12执行FLUSH LOG进行日志刷盘。

      5.使用undo日志进行数据库的恢复

      现在假设系统故障发生了。有可能给定事务的某些数据库更新已经写到磁盘上,而同一事务的另外一些更新尚未到达磁盘。如果这样,事务的执行就不是原子的,数据库状态就可能不一致。这时候,我们就有必要使用日志将数据库恢复到一致的状态。

      比如,在表2中,如果故障发生在步骤9之后、步骤10之前。数据库的状态就是不一致的。

      恢复管理的第一个任务就是将事务划分为已经提交事务和未提交事务。如果在日志中,根据undo的规则2,事务T所做的全部改变在此之前已经写到磁盘上,因此当故障发生时,该事务T不可能导致数据库的不一致状态。

      然而,假设在日志中,只有记录,而没有与之相匹配的记录。那么就有可能在崩溃前,事务的某些修改已经反应到磁盘上,而另外一些修改可能未发生或者还在缓冲区中。这种情况下,T是一个未完成的事务,因为必须被撤消。也就是说,T所做的任何修改都必须恢复为原来的值。Undo的规则1使该想法可以成为可能,因为在修改数据刷盘之前,日志文件中已经保存了修改数据的原先值。对于,只需要将X的值恢复为v就行了(我们不必检查数据库中X现有值是否为v)。

      日志中可能有一些未提交的事务,并且甚至可能有一些未提交的事务修改了X,所以恢复时采用从日志文件尾向前扫描。在扫描过程中记住所有有或记录的事务T。同时在随后的扫描中,如果它看见,则:

      1) 如果T的COMMIT记录已被扫描到,则什么也不做。

      2) 否则,将数据库中元素X的值改为v。在做完这些操作后,为以前未中止且未完成的每个事务T写入一个日志记录,然后刷新日志。

      对于表2,作如下分析:

      1)崩溃在第12步后发生。因为日志记录已经写入日志文件。当恢复时,不需要处理T事务。

      2)崩溃发生在11步和12步之间。日志中记录了三条记录:、以及。当恢复管理进行向后扫描时,首先遇到记录,于是它将B在磁盘上的值存为500。接着它遇到记录,于是它将A在磁盘上的值存为1000。最后记录被写到日志中且日志被刷新。

      3)崩溃发生在第8步和第11步之间。情况2一样。

      4)崩溃发生在第8步之前。日志系统中只有一条记录:。记录被写到日志中且日志被刷新。(实际上,在实际系统中,可能其他的事务执行FLUSH LOG操作,而将事务T的日志记录写入磁盘中,如果是这样的话,日志中可能已经写入和,对于这种情况,执行情况2的恢复就行。实际上这些细节不影响undo的恢复效用,为了简单起见,忽视这些情况)。

      6.静态检查点

      正如我们所看到的那样,恢复时需要检查整个日志。当采用undo类型的日志时,一旦日志记录被写入日志文件,事务T的日志记录就可以忽视了。但是此时事务T却不能截断日志,因为事务是交替执行的,如果这时将日志截断,可能丢失活动着的事务的日志记录。

    解决该问题的方法是周期性地对日志做检查点。步骤如下:

      1)停止接受新的事务

      2)等待所有当前的活动事务提交或终止,并且在日志文件中写COMMIT或ABORT记录。

      3)将日志刷新到磁盘

      4)写入日志记录,并再次刷新记录。

      5)重新开始接受新事务。

      当恢复事,扫描到日志时,就不需要继续扫描日志记录了。

      例如:假设日志开始时是这样的:

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

      这时候,我们做一个检查点。等待事务T1和事务T2都完成,才在日志文件中写记录。检查点做完后,可以接受新的事务,这里为事务T3,T3执行了一些操作,此时系统崩溃了。日志文件的内容如下:

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

     

    <T2, C, 15>

     

    <T1, D, 20>

     

    <COMMIT T1>

     

    <COMMIT T2>

     

    <CKPT>

     

    <START T3>

     

    <T3, E, 25>

     

    <T3, F, 30>

      恢复时,从文件尾部开始扫描,因为T3是未完成事务,则将磁盘上F的值存为前值30、磁盘上E的值存为前值25。当扫描到日志记录时,我们知道没有必要检查以前的日志记录了,并且数据库状态的恢复已经完成。

      7.非静态检查点

      静态检查点的缺点在与,可能需要很长时间等待活跃事务的完成,在用户系统看来似乎是静止了。非静态检查克服了该缺点,在做检查点时允许新事务进入。步骤如下:

      1) 写入日志记录.其中T1,……,Tk为活跃事务。

      2) 等待T1,……,Tk每一个事务提交或终止,但允许其它事务开始。

      3) 当T1,……,Tk都已完成时,写入日志记录并刷新日志。

      当系统发生故障时,从日志尾部开始扫描日志。根据扫描过程中先遇到记录还是记录,有两种情况。

      1) 如果先遇到记录。所有未完成的事务在记录后开始,只要扫描到。就不需要继续扫描了。前的记录是可以截断的。

    2) 如果先遇到,那么崩溃发生在检查点过程中。未完成事务只可能是到达前遇到的那些,以及T1,……,Tk在崩溃前未完成的那些。因此只要继续扫描到未完成事务中最早的那个事务的开始就行了。

      一个通常的规律是,一旦记录到了磁盘,我们就可以将上一个记录前的日志删除了。

      例如:假设日志开始时是这样的:

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

      现在我们决定做一非静态检查点。因为事务T1和T2是活动的,我们写入记录。在等待T1和T2完成时,事务T3开始了。

      执行到崩溃时,日志记录可能如下(对应恢复的第一种情况):

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

     

    <START CKPT(T1,T2)>

     

    <T2, C, 15>

     

    <START T3>

     

    <T1, D, 20>

     

    <COMMIT T1>

     

    <T3, E, 25>

     

    <COMMIT T2>

     

    <END CKPT>

     

    <T3, F, 30>

      对于这种情况,恢复时,从尾部开始检查日志。T3是未完成的事务,将磁盘上的F值恢复为值30。发现记录,知道所有未完成的事务从前一个START CKPT开始。继续扫描,将磁盘上E的值恢复为25。继续扫描,发现没有其它已开始但尚未提交的事务。恢复完成。

      当然,崩溃时的日志记录可能是另外一种格式,如下: 

     

    <START T1>

     

    <T1,  A, 5>

     

    <START T2>

     

    <T2, B, 10>

     

    <START CKPT(T1,T2)>

     

    <T2, C, 15>

     

    <START T3>

     

    <T1, D, 20>

     

    <COMMIT T1>

     

    <T3, E, 25>

      对于这种情况,崩溃发生在检查点过程中。向后扫描,确定T3然后又确定T2是未完成事务,并撤消它们所做的修改。当到达时,我们知道其它可能未完成的事务只有T1了,但是T1的记录已经发现。我们也发现了。所以我们只要继续扫描到记录,并在此过程中将磁盘B的值恢复成10。

    三:redo记录

      1.概述

      Undo是恢复的一种策略,但是不是唯一的策略。

      Undo日志的一个潜在的问题是:在所有修改数据没有写到磁盘前,不允许提交该事务。有时,让修改的数据页暂时缓冲在主存中,是可以节省磁盘IO的;只要在崩溃的时候有日志用来恢复。

      2.redo日志的规则

      Redo日志用新值表示数据元素的更新,而undo日志使用的是旧值。Redo日志的表示:事务T为数据库元素X写入新值v。

      Redo日志系统的规则只有一条:

      规则1:在修改磁盘上任何数据库元素X之前,要保证所有与X这一修改相关的日志记录,包括更新记录以及记录,都必须出现在磁盘上。

      Redo日志顺序如下:

      1) 指出被修改元素的日志记录

      2) COMMIT日志记录

      3) 改变的数据元素自身。

      3.应用

      对于前面所举的例子(A转帐50元给B帐号),如果使用了undo日志系统,则相关的工作流程如表3如下。

    表3:redo日志系统的工作原理

     

     

    步骤

     

    动作

     

    t

     

    内存A

     

    内存B

     

    磁盘A

     

    磁盘B

     

    undo日志

     

    1

     

     

     

     

     

     

     

     

     

     

     

     

     

    <START T>

     

    2

     

    READ(A,t)

     

    1000

     

    1000

     

     

     

    1000

     

    500

     

     

     

    3

     

    t := t-50

     

    950

     

    1000

     

     

     

    1000

     

    500

     

     

     

    4

     

    WRITE(A,t)

     

    950

     

    950

     

     

     

    1000

     

    500

     

    <T, A, 950>

     

    5

     

    READ(B,t)

     

    500

     

    950

     

    500

     

    1000

     

    500

     

     

     

    6

     

    t := t+50

     

    550

     

    950

     

    500

     

    1000

     

    500

     

     

     

    7

     

    WRITE(B,t)

     

    550

     

    950

     

    550

     

    1000

     

    500

     

    <T, B, 550>

     

    8

     

     

     

     

     

     

     

     

     

     

     

     

     

    <COMMIT T>

     

    9

     

    FLUSH LOG

     

     

     

     

     

     

     

     

     

     

     

     

     

    10

     

    OUTPUT(A)

     

    550

     

    950

     

    550

     

    950

     

    500

     

     

     

    11

     

    OUTPUT(B)

     

    550

     

    950

     

    550

     

    950

     

    550

     

     

      与记录的是新值。只有所有相关的日志记录被刷盘(步骤9),才允许将A与B的新值写到磁盘。步骤10与11在日志刷盘之后立即将数据修改写到磁盘,而实际中为了提高IO命中率,刷盘的时间可能会晚些。

     4.使用redo日志的恢复

      对于redo日志,根据规则1,我们可以知道如果日志没有,则事务T的修改所做的所有的更新都没反映到磁盘上,就像事务T从来没有发生过一样。

      如果发现记录记录,却不敢保证所有的数据库修改已经反映到磁盘上,这和undo日志是相反的。我们必须将事务T重做一次。

      使用redo日志恢复,过程如下:

      1) 确定提交事务

      2) 从首部开始扫描日志,对遇到的每一记录:

      (a):如果T是未提交的事务,则什么也不做。

      (b):如果T是提交的任务,则为磁盘上数据库元素写入值v

      3)对于每一个未完成的事务T,在日志中写入一个记录并刷新日志。

      例如,对于表3

      1) 如果故障发生在第9步以后,记录已被刷新到磁盘。恢复时,遇到记录,为磁盘上的A写入值950。遇到记录,为磁盘上的B写入值550。

      2) 如果故障发生在第9步之前,如果已经到达磁盘,则恢复过程同情况1。如果未到达磁盘,T被做为未完成事务,磁盘上的A和B不作任何修改,最后将一条写入日志并刷盘。

     

    展开全文
  • 数据库日志采集系统方案设计

    千次阅读 2022-01-07 13:33:19
    汽车之家几年前已实现了应用日志的采集,但是对数据库日志并没有实现集中采集,排查定位数据库故障原因不便。2021年我们研发了数据库日志采集分析平台系统,实现了数据库主机系统日志,数据库错误日志,审计日志的采集...

    前言

    汽车之家几年前已实现了应用日志的采集,但是对数据库日志并没有实现集中采集, 排查定位数据库故障原因不便。2021年我们研发了数据库日志采集分析平台系统,实现了数据库主机系统日志,数据库错误日志,审计日志的采集和分析。

    01

    背景介绍

    之家数据库日志以前分散在各DB宿主机及容器RDS上,没有实现集中采集,排查定位故障原因不便。2021年DBA研发了数据库日志采集分析平台,实现了主机系统日志,数据库错误日志,审计日志的采集和分析。通过日志的集中采集,提升了故障排查效率,并且深入挖掘日志价值,可为未来之家数据库的智能审计,智能运维(如故障预警,自愈,自动调优)提供基础。

    02

    日志分析发展历程

    日志分析并不是一项新颖的技术了,需要的是实际解决问题的思路或工具,哪怕是一段只有20行的命令脚本都可以。日志分析的发展划可分成4个时代:

    1.石器时代 : 石器时代日志分析通常依靠Excel、终端命令(awk、grep、sort、uniq、wc等)。

    2. 铁器时代 :  铁器时代通常依靠脚本工具(自写工具)、简易交互式工具(logwatch、logparser)等。

    3. 工业时代 : 工作时代大家在做日志分析的时候相比前两个时代已经有了太多 的进步了,各种开源、免费、付费的软件可供选择,比如:Elastic系列、Splunk等等。

    4. 未来时代 : 这个时代大家在做日志分析时候我不知道会用到什么,但是从目前来看,机器学习、人工智能应该是核心之一。

    统一日志分析平台的工作在看来可以简单 分为2个阶段:

    平台实现: 日志规范化 --> 日志采集 --> 日志存储 --> 日志分析 --> 日志展示 --> 告警实现;

    平台优化: 这个阶段是对平台实现中的每一个步骤进行优化。

    以下对常见的开源日志采集工具做一 简单分析:

    03

    方案设计

    之家数据库日志平台,可以分为应用层,日志采集层,缓存层,解析层,存储层,展示层,系统架构如 图1 。

    图 1 日志采集架构图

    04

    方案实施

    通过之家二次开发的log-pilot日志采集工具,对数据库机器系统日志、DB错误日志、审计日志进行采集。采集的日志数据存入Kafka,为避免和其它业务日志相互影响, DBA采集申请了独立的KAFKA集群与Topic进行隔离。消费KAFKA数据采用Flink,对数据库日志数据进行处理,优化,精简,最终日志存入Elasticsearch。日志展示使用了开源的Kibana。 即数据流为日志源文件→ Log-pilot→ Kafka→ Flink→ ELasticsearch→ Kibana展示。

    采集的数据库日志有错误日志,审计日志等,各种日志数据格式不统一,我们进行了日志规范化处理。其中审计日志支持json格式,DBA开发了Flink Api,Flink任务启动加载引用python包进行json数据处理赋值给ES索引字段。

    另外为了高效运维管理数据库日志,做了如下工作:

    • 日志可视化配置管理: 开发了日志配置管理界面,可以对DB实例进行日志路径配置,日志采集启停。

    • 日志监控报警: 对ERROR或敏感数据审计日志,上报公司监控告警平台(AutoCMP),对重要日志信息及时发现并通知到告警接收人。

    05

    平台展示

    图 2 数据库物理实例日志采集

    图 3 采集日志Dashboard展示

    图 4 数据库日志报警

    06

    展望

    未来计划增加重点数据库的SQL日志采集,通过分析SQL对高危操作。比如:DROP/TRUNCATE,DELETE等SQL语句执行进行审计监控报警。对数据库中warning/error等问题进行分析治理,进一步提升数据库服务质量。

    展开全文
  • 达梦数据库启用日志方法,达梦数据库查看日志是否启用,达梦数据库日志文件位置查找。 注: 日志启用时会非常占用硬盘的读写资源,使正常读写数据库的效率大大降低,因为日志文件很大,之前我们有个服务器一直起着...
  • SQL SERVER 数据库日志占用很大的空间 ,如果长时间不清除,就会影响数据存储。 一、工具原料 sql server 二方法、步骤 1、打开sql server 数据库 在菜单中选择新建查询 2、选择master数据库 3、在sql执行窗口执行...
  • SQL日志查看 查询数据库日志详细

    热门讨论 2010-10-23 23:17:31
    SQL 日志 查看 查询数据库日志 详细 含注册码
  • 数据库日志整理

    千次阅读 2018-07-20 08:51:33
    数据库日志整理 Database : log, redolog, undolog, commandlog 幂等性 数据库日志文件中的操作记录应该具有幂等性,同一个操作执行多次,结果是一样的。因为日志在故障恢复过程中,可能会被回放多次。 ...
  • MySQL数据库日志的查看

    万次阅读 2018-11-10 19:49:43
    MySQL数据库日志,默认是没有打开,所以需要进入到MySQL配置文件中,进行相关的配置; 进入到配置文件的相关命令: sudo subl /etc/mysql/mysql.conf.d/mysqld.cnf 这里我是通过subline打开的,大家也可以通过vi...
  • Oracle数据库查看日志

    千次阅读 2021-04-30 08:27:45
    查看文本日志: cd /opt/oracle/app/oracle/diag/rdbms/amsesa/amsesa/trace ls -l | grep log tail -1000f alert_amsesa.log 查看alert日志: cd /opt/oracle/app/oracle/diag/rdbms/amsesa/amsesa/alert tail -...
  • ORACLE数据库日志路径查询 看这篇文章,相信都比较小白。 首先:要明白数据库日志就是alter日志,下面的就可以正常理解了。 查看alter数据库日志路径方法: 1、登录Oracle服务器,切换到oracle用户(数据库用户)下 ...
  • 数据库日志收缩

    千次阅读 2019-03-21 11:39:07
    背景 因数据库日志文件(.log)不断增加,导致硬盘可用容量不断减少; 解决方法 数据库自动收缩 设置如下: 右键数据库–属性–选项–选择"自动收缩" ; ...
  • sql server收缩数据库日志

    千次阅读 2019-05-28 22:59:28
    平常我们会碰到数据库日志文件很多的情况,这个时候我们就需要如何收缩日志 收缩的文件夹如下所示: E:\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA 步骤如下: 第一步:备份日志 登入到主数据库 ...
  • 如何查看数据库日志

    千次阅读 2019-07-05 03:01:44
    在SQL Server中,一个数据库日志是以*.ldf 文件存放,请问我想查看某一个数据库日志,该如何操作.方法1: DBCCLOG('DatabaseName',2) 方法2: select*From::fn_dblog(default,default) 方法3: 用Log...
  • SQLServer2012清理数据库日志文件

    千次阅读 2019-11-19 15:14:48
    惊呆了有没有,然后查看了一下c盘文件,发现一个数据库日志文件14gb,顿时闷逼。这个数据库还有用又不能删… 去网上找了一坨资料,说的都是啥玩儿,我对SQLServer又不熟。。。于是在自己的摸索下,把这个数据库日志...
  • MySQL查询数据库日志的查询

    千次阅读 2018-11-14 21:49:03
    一、查看mysql数据库日志可以查看对数据库的操作记录。 mysql日志文件默认没有产生,需要做如下配置: 1.打开mysql的配置文件 sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf 2.修改配置文件的第68、69行,将#去掉,...
  • sql server 数据库日志文件太大该如何处理 在工作中,有时候需要对sql server数据库进行大量且频繁的插入、删除操作,这种操作会使得sql server数据库日志文件增长得非常快,这时很容易引起一个问题——服务器剩余...
  • 本文主要向大家介绍了MySQL数据库之mysql日志文件在哪 如何修改MySQL日志文件位置 ,通过具体的内容向大家展现,希望对大家学习MySQL数据库有所帮助。MySQL日志文件相信大家都有很多的了解,MySQL日志文件一般在:/...
  • MySQL数据库日志的打开方法

    千次阅读 2019-06-23 14:13:41
    查看MySQL数据库日志 查看mysql数据库日志可以查看对数据库的操作记录。 mysql日志文件默认没有产生,需要做如下配置: sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf 把68,69行前面的#去除,然后保存并...
  • 开启并查看Mysql数据库日志信息

    千次阅读 2019-06-29 23:19:17
    查看Mysql数据库日志信息可以查看对数据库的操作记录,对于Mysql数据库日志默认是没有开启的,需要进行如下配置: sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf 把68,69行前面的#去除,然后保存并使用如下...
  • 查看数据库日志文件及路径

    千次阅读 2019-02-16 17:44:40
    select * from v$asm_diskgroup -----...select * from v$diag_info where name=‘Default Trace File’---------------查看trace路径,找到数据库日志文件 /u01/app/oracle/diag/rdbms/hdyldb/hdyldb1/trace/hdyldb...
  • 数据库日志无法收缩

    千次阅读 2017-09-14 22:14:28
    在论坛里面经常有人遇到,数据库日志文件无法收缩的问题。这里详细介绍下这个问题怎么解决。
  • MySQL 数据库管理之 --- 日志查询

    万次阅读 2021-10-26 12:23:45
    查看日志2.1 查看错误日志是否开启2.2 查看通用查询日志是否开启2.3 查看二进制日志是否开启2.4 查看慢查询日功能是否开启2.5 查看慢查询时间设置2.6 在数据库设置开启慢查询的方法 前言 备份的主要目的是灾难...
  • 归档日志:完整记录对数据库的全部操作. 1重做日志文件记录对数据操作,而且重做日文件是循环使用的, 当所有的日志文件被塞满时候,系统自动切换到第一组日志文件。 接下来 2在循环使用日志文件时,日志文件存在...
  • 如何查询Oracle数据库的操作日志

    千次阅读 2021-05-07 05:12:24
    打开之后不需要连接数据库就可以查询到sql记录了。2、在二级菜单中,选择SQL历史记录选项,或者按快捷键F8打开窗口。3、默认打开是会显示在最下方的小窗口,在标题栏双击鼠标左键,即可最大化窗口,再次双击左键还原...
  • 深入理解数据库日志系统原理

    千次阅读 2016-02-29 21:20:30
     事务管理系统需要做两件事,1)让日志系统产生日志,2)保证多个事务并发执行,满足ACID特性。  事务系统工作模型,见图1。    如图,事务管理管理器控制查询处理器的执行、控制日志系统以及缓冲区。日志在...
  • 解决数据库日志文件过大的问题

    千次阅读 2019-08-06 15:54:29
    随着数据库使用时间增长,日志文件也在不停的增大,这里介绍几种方法减小这个文件的方法。 1.直接删除log文件 分离数据库。分离数据库之前一定要做好数据库的全备份,选择数据库——右键——任务——分离,如下图 ...
  • 在新增用户时总是插入为空。所有需要打印数据库日志查看具体详情。 我使用的是application.properties文件,加入如下配置: logging.level.com.dao=debug

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,012,210
精华内容 404,884
关键字:

如何设置数据库日志