10. 日志

aloha_
160 阅读14分钟

数据库日志记录

数据库日志记录是数据库管理系统（DBMS）用于记录数据库操作和事务信息的重要机制。数据库日志记录通常包括事务日志（Transaction Log）和恢复日志（Recovery Log），用于确保数据的一致性、完整性和持久性。

事务日志（Transaction Log）

事务日志记录了数据库中每个事务的操作过程，包括事务的开始、提交或回滚等信息。事务日志通常记录在事务执行之前和之后的状态，以便在发生故障或错误时进行回滚或恢复操作。通过事务日志，数据库可以实现事务的原子性、一致性和持久性。

事务日志格式：

[时间戳][事务ID][操作类型][表名][操作描述]
[2022-01-01 10:00:00] [T123] [START] [Users] [ Start transaction for updating user information]

恢复日志（Recovery Log）

恢复日志记录了数据库中发生的所有变更操作，包括插入、更新和删除等操作。恢复日志通常记录在事务提交之前和之后的数据状态，以便在系统崩溃或故障时进行数据恢复。通过恢复日志，数据库可以实现数据的持久性和一致性。

恢复日志格式：

[时间戳][事务ID] [操作类型][表名][主键值][字段名] [旧值][新值]
[2022-01-01 10:00:00] [T123] [UPDATE] [Users] [UserID=123] [UserName] [John] [Jane]

数据库日志记录的作用包括：

  • 提供事务的原子性：通过记录事务的操作过程和状态变化，确保事务要么完全执行，要么完全回滚。
  • 提供事务的一致性：通过记录数据的变更操作，确保数据库的一致性和完整性。
  • 提供数据的持久性：通过将数据变更写入日志文件，确保数据在系统故障或错误时不会丢失。

这两种类型的日志文件通常是分开维护的，以区分事务信息和数据更新信息。事务日志用于记录事务的执行过程和状态变化，而恢复日志用于记录数据的变更操作。

基于日志的恢复技术

基于日志的恢复技术是数据库系统用于保证数据一致性和持久性的关键机制之一。通过记录数据库操作的日志信息，系统可以在发生故障或错误时进行数据恢复，确保数据库的可靠性和完整性。基于日志的恢复技术通常包括以下几个步骤：

  1. 日志记录（Logging）：数据库系统在执行事务操作时会将操作的日志信息记录到事务日志中。日志记录包括事务的开始、提交或回滚等操作，以及对数据的修改操作（如插入、更新、删除）。数据库系统会先将日志信息写入日志缓冲区，然后异步地将日志信息写入磁盘的日志文件。

  2. 数据更新（Data Update）：在执行事务操作时，数据库系统会先将数据的修改操作写入日志文件，然后再将数据的修改操作应用到数据库中。这样可以确保即使在数据写入磁盘之前发生系统崩溃或错误，系统也可以通过日志文件进行数据恢复。

  3. 恢复过程（Recovery Process）：当数据库系统发生故障或错误时，系统会通过恢复管理器（Recovery Manager）来进行数据恢复。恢复过程通常包括两个阶段：重做（Redo）和撤销（Undo）。

    • 重做：系统会先通过事务日志中的信息重新执行已提交的事务操作，将未来完成的数据更新操作重新应用到数据库中，以确保数据的最新状态。（简言之，已经提交了commit的事务日志记录，就会将其重新入库，保证最新的数据）
    • 撤销：系统会检查事务日志中的信息，找到未提交的事务操作并撤销这些操作，将数据库恢复到事务发生前的状态。（简言之，没有commit的日志，旧值代替新值，对一个事务多次执行都是一样）

重做日志格式：

[时间戳][事务ID][操作类型][表名] [主键值][字段名][新值][旧值]
[2022-01-01 10:10:00] [T124] [UPDATE] [Users][UserID=123] [UserName] [John] [Jane]

撤销日志格式：

[时间戳][事务ID][操作类型][表名] [主键值][字段名][新值][旧值]
[2022-01-01 10:10:00] [T124] [UPDATE] [Users][UserID=124] [UserName] [Alice] [Bob]

Mysql中的Undo日志和Redo日志

在MySQL中，Undo日志和Redo日志是存储在InnoDB存储引擎内部的，用于支持事务的ACID属性（原子性、一致性、隔离性、持久性）。这两种日志对于数据库的恢复和数据一致性非常重要，在MySQL中用户无法直接访问或查看这些日志文件。

  1. Undo日志（Undo Log）：
  • Undo日志用于记录事务执行过程中对数据的修改操作，主要用于事务的回滚操作和MVCC（多版本并发控制）
  • Undo日志存储在InnoDB的Undo表空间中，用于存储事务执行前的数据版本，以便在事务回滚或MVCC时使用。
  • Undo日志的存在可以确保事务在执行过程中对数据的修改操作可以被回滚，从而保证事务的原子性和一致性
  1. Redo日志（Redo Log）：
  • Redo日志用于记录事务执行过程中对数据的修改操作，主要用于事务的持久性。
  • Redo日志存储在InnoDB的Redo日志文件中（通常是ib_logfile*文件），用于存储事务对数据的修改操作，以便在数据库崩溃或故障后进行恢复。
  • Redo日志的存在可以确保在数据库恢复过程中可以重新执行已提交事务的修改操作，从而保证数据的持久性。

简而言之，Undo保证事务的原子性和一致性，Redo保证数据的持久性。

Mysql的Binlog日志

为什么还要有binlog呢？

虽然Undo日志和Redo日志在InnoDB存储引擎中起着重要的作用，但Binlog（二进制日志）在MySQL中仍然是必不可少的，主要原因包括以下几点：

  1. 数据备份与恢复：
  • Binlog记录了数据库中的所有数据更改操作，包括INSERT、UPDATE、DELETE等，可以用于数据备份和恢复。通过恢复Binlog，可以将数据库恢复到特定时间点的状态，实现数据的灾难恢复和备份。
  1. 主从复制：
  • Binlog用于支持MySQL的主从复制（Replication）功能，主服务器会将其更改操作记录到Binlog中，从服务器则通过读取Binlog来同步主服务器的数据更新操作。Binlog在主从复制中起着至关重要的作用，确保从服务器与主服务器的数据一致性。
  1. 数据库迁移和同步：
  • Binlog可以用于数据库迁移和同步，通过将Binlog应用到目标数据库中，可以实现数据的迁移和同步，保持数据的一致性。
  1. 数据恢复和故障恢复：
  • 在数据库故障或意外删除数据时，Binlog可以用于恢复数据的操作序列，从而实现数据的恢复。

简而言之，就是Undo日志和Redo日志属于数据库引擎InnoDB的，而binlog是属于Mysql server层面的。

这三种日志相互配合，形成一个完整的数据管理和保护系统，为数据库提供了多层次的数据保护机制。

binlog的刷盘时机

在MySQL中，binlog的刷盘时机通常取决于数据库的日志刷盘策略和配置。以下是一些常见的binlog刷盘时机：

  1. 提交事务时刷盘（Write-Ahead Logging）（默认机制）：
  • MySQL使用Write-Ahead Logging（WAL）技术，即在事务提交时将binlog日志写入磁盘。
  • 当事务提交时，MySQL会将事务的操作记录到binlog中，并将binlog日志写入磁盘，以确保事务的持久性。
  • 这种刷盘时机可以保证数据的一致性，但可能会影响性能。
  1. 定期刷盘（Periodic Flushing）：
  • MySQL也支持定期刷盘的方式，即定期将binlog日志写入磁盘，而不是等待事务提交时才刷盘。
  • 通过定期刷盘，可以减少磁盘IO的频率，提高性能，但可能会增加数据丢失的风险。
  1. 异步刷盘（Asynchronous Flushing）：
  • MySQL还支持异步刷盘的方式，即将binlog日志写入磁盘的操作交给后台线程异步处理，不阻塞主线程。
  • 异步刷盘可以提高性能，减少对主线程的影响，但可能会增加数据丢失的风险。

sync_binlog参数控制biglog的刷盘时机，取值范围是0-N：

  • 0：不去强制要求，由系统自行判断何时写入磁盘；
  • 1：每次commit的时候都要将binlog写入磁盘；
  • N：每N个事务，才会将binlog写入磁盘。

建议使用提交事务时刷盘的方式，以确保数据的一致性和持久性。如果对性能要求较高，可以考虑使用定期刷盘或异步刷盘的方式，但要注意可能带来的数据丢失风险。

那Undo/Redo/Binlog日志记录顺序是什么呢？

  1. 数据更改操作
  • 用户执行数据更改操作（如INSERT、UPDATE、DELETE）时，首先将操作记录到Redo日志中；
  • 同时，数据库会将操作记录到Undo日志中，以在事务回滚或MVCC（多版本并发控制）时使用。
  1. 事务提交：
  • 在事务提交时，数据库会将操作记录到Binlog中，以确保数据的备份和主从复制的一致性。
  1. 数据恢复：
  • 当数据库发生故障或需要恢复数据时，可以通过Redo日志和Binlog来恢复数据的更改操作，确保数据的一致性和完整性。
  • Undo日志可以用于事务回滚或MVCC，以撤销未提交事务的更改操作。
  1. 主从复制：
  • 主服务器会将更改操作记录到Binlog中，从服务器通过读取Binlog来同步主服务器的数据更改操作，以保持数据的一致性。

案例

假设有一个银行账户数据库，其中包含账户信息和交易记录。现在用户A要向用户B转账100元钱，这个操作涉及到两个账户的数据更新操作。下面是基于日志的恢复技术的一个简单示例：

  1. 用户A发起转账请求，系统开始执行转账操作：
  • 系统记录转账操作的日志信息，包括事务开始记录和转账操作的相关信息（如转出账户、转入账户、金额等）。
  • 系统将转出账户的余额减去100元，并将转入账户的余额加上100元。
  1. 在执行转账操作期间，系统发生了故障，导致系统崩溃：
  • 因为转账操作的日志信息已经被记录，系统可以通过日志文件进行数据恢复。
  1. 系统重启后，系统启动恢复过程：
  • 系统先进行重做（Redo）操作：通过事务日志中的信息重新执行已提交的事务操作，将转账操作重新应用到数据库中，确保转账操作的数据更新生效。
  • 然后系统进行撤销（Undo）操作：系统检查事务日志中的信息，找到未提交的事务操作（如转账操作），并撤销这些操作，将数据库恢复到事务发生前的状态。

数据库的延时更新和即时更新技术

数据库的延时更新和即时更新是两种不同的数据更新策略，用于管理数据库中数据的更新操作。这两种更新技术在性能、一致性和可靠性方面有不同的影响。

延时更新（Deferred Update）

  • 在延时更新技术中，数据库系统将更新操作暂时保存在事务日志中，而不立即将更新应用到数据库中。
  • 当事务提交时，数据库系统将事务日志中的更新操作应用到数据库中，确保事务的一致性。
  • 延时更新可以提高数据库系统的性能，因为可以减少频繁的磁盘写入操作。但是在事务提交前，数据更新操作并不立即生效，可能会导致数据的读取和更新之间存在不一致性。

即时更新（Immediate Update）

  • 在即时更新技术中，数据库系统在执行更新操作时立即将更新应用到数据库中，确保数据的实时性和一致性。
  • 当事务提交时，更新操作立即生效，其他事务可以立即看到更新后的数据。
  • 即时更新可以保证数据的实时性和一致性，但可能会增加磁盘写入的频率，影响数据库系统的性能。 选择延时更新还是即时更新取决于具体的应用场景和需求：
  • 如果对数据的实时性要求不高，且需要提高数据库系统的性能，可以选择延时更新技术。
  • 如果对数据的实时性和一致性要求较高，且能够接受一定的性能损失，可以选择即时更新技术。

在实际应用中，需要根据具体情况综合考虑数据的更新频率、对数据一致性的要求、系统的性能需求等因素来选择合适的更新技术。同时，需要注意在使用延时更新技术时，确保在事务提交前数据的一致性和可靠性。

日志恢复技术

在实际的生产环境中，日志文件非常的大，恢复起来非常费时。就用到了检查点技术。

检查点

检查点（Checkpoint）是数据库系统中的一个重要概念，用于创建一个一致的数据库快照，以减少数据库恢复时间和提高系统性能。检查点的原理如下：

  1. 内存中的数据和日志：
  • 在数据库系统中，数据通常首先被写入内存缓冲区中进行修改操作，然后再异步地写入磁盘中的数据文件。
  • 同时，数据库系统会将事务的操作记录到日志文件中，以便在发生故障时可以通过日志进行恢复。
  1. 创建检查点：
  • 当数据库系统需要创建一个检查点时，会将内存中的数据和日志写入磁盘中的数据文件，以创建一个一致的数据库快照。
  • 创建检查点的过程中，会将内存中的数据刷新到磁盘，确保数据的持久性和一致性。
  1. 日志刷盘：
  • 在创建检查点时，数据库系统会将所有未写入磁盘的日志记录刷盘（写入磁盘），以确保日志的持久性。
  • 这样可以确保在数据库系统发生故障时，可以通过日志进行恢复，将数据恢复到检查点之后的状态。
  1. 减少恢复时间：
  • 创建检查点的过程中，数据库系统会记录检查点的位置，以便在系统恢复时可以从检查点位置开始进行日志恢复，缩短数据库的恢复时间。
  • 通过定期执行检查点操作，可以减少数据库恢复时间，提高系统性能和可靠性

image.png

avatar
文章
阅读
粉丝