MySQL에서 binlog/redolog/undolog의 차이점은 무엇입니까?-MySQL 튜토리얼-php.cn

MySQL binlog/redolog/undolog의 차이점은 무엇인가요?

InnoDB의 잠금 메커니즘에 대해 이야기하고 싶기 때문에 필연적으로 MySQL 로그 시스템, binlog, redo 로그, undo 로그 등이 포함됩니다. 일부 친구가 요약한 이 세 가지 로그는 나쁘지 않은 것으로 확인했습니다. 서둘러서 가져와서 모든 친구들과 공유하세요.

로그는 mysql 데이터베이스의 중요한 부분으로, 데이터베이스 운영 중 다양한 상태 정보를 기록합니다. mysql 로그에는 주로 오류 로그, 쿼리 로그, 느린 쿼리 로그, 트랜잭션 로그 및 바이너리 로그가 포함됩니다. mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。

作为开发，我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)，本文接下来会详细介绍这三种日志。

bin log

binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志。

逻辑日志：可以理解为记录的就是sql语句.
物理日志：mysql数据最终是保存在数据页中的，物理日志记录的就是数据页变更。

binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。

在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。

主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
数据恢复：通过使用mysqlbinlog工具来恢复数据。

binlog刷盘时机

对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中，那么biglog是什么时候刷到磁盘中的呢？

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

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

从上面可以看出，sync_binlog最安全的是设置是1，这也是MySQL 5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。

binlog日志格式

binlog日志有三种格式，分别为STATMENT、ROW和MIXED。

在MySQL 5.7.7之前，默认的格式是STATEMENT，MySQL 5.7.7之后，默认值是ROW。日志格式通过binlog-format指定。

STATMENT：基于SQL 语句的复制( statement-based replication, SBR )，每一条会修改数据的sql语句会记录到binlog 中。
ROW：基于行的复制(row-based replication, RBR )，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了。
MIXED：基于STATMENT 和 ROW 两种模式的混合复制(mixed-based replication, MBR )，一般的复制使用STATEMENT 模式保存 binlog ，对于 STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog

redo log

为什么需要redo log

我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。

那么mysql
개발자로서 우리가 집중해야 할 것은 바이너리 로그(binlog)와 트랜잭션 로그(redo 로그 및 undo 로그 포함)입니다. ) 이 글에서는 이 세 가지 유형의 로그에 대해 다음에 자세히 소개하겠습니다.
bin log🎜🎜binlog는 데이터베이스에서 수행된 쓰기 작업(쿼리 제외) 정보를 기록하는 데 사용되며 바이너리 형식으로 디스크에 저장됩니다. binlog는 mysql의 논리적 로그이며 Server 계층에 의해 기록됩니다. 모든 스토리지 엔진을 사용하는 모든 mysql 데이터베이스입니다. binlog 로그를 기록합니다. 🎜

🎜논리로그 : sql문장으로 기록되는 것으로 알 수 있다.🎜

🎜물리로그 : mysql data 최종적으로는 데이터 페이지에 저장되며, 물리적 로그에는 데이터 페이지 변경 사항이 기록됩니다. 🎜

🎜binlog는 추가해서 작성하며, 각 binlog는 max_binlog_size 매개변수를 통해 설정할 수 있습니다. 파일 크기가 지정된 값에 도달하면 로그를 저장하기 위한 새 파일이 생성됩니다. 🎜🎜실제 응용 프로그램에는 binlog의 두 가지 주요 사용 시나리오, 즉 마스터-슬레이브 복제와 데이터 복구가 있습니다. 🎜

🎜마스터-슬레이브 복제: 마스터 측에서 binlog를 연 다음 binlog각 <code>Slave 끝으로 보내면 Slave 끝은 binlog를 재생하여 마스터-슬레이브 데이터 일관성을 달성합니다. 🎜

🎜데이터 복구: mysqlbinlog 도구를 사용하여 데이터를 복구하세요. 🎜

binlog 플러시 타이밍
🎜InnoDB 스토리지 엔진의 경우 biglog는 트랜잭션이 커밋될 때만 기록됩니다. >, 기록은 현재 메모리에 남아 있는데 biglog가 언제 디스크에 플러시되었습니까? 🎜🎜mysql은 sync_binlog 매개변수를 통해 biglog의 플러시 타이밍을 제어합니다. 값 범위는 0-N입니다. 🎜

🎜0: 필수 요구 사항은 없으며 시스템이 디스크에 쓸 시기를 결정합니다. 🎜

🎜1: 모든 커밋 , binlog는 디스크에 기록되어야 합니다. 🎜

🎜N: binlog는 N개의 트랜잭션 디스크마다 기록됩니다. 🎜

🎜위에서 볼 수 있듯이 sync_binlog에 대한 가장 안전한 설정은 1이며 MySQL 5.7.7이기도 합니다. code> 이후 버전의 기본값입니다. 그러나 더 큰 값을 설정하면 데이터베이스 성능이 향상될 수 있으므로 실제 상황에서는 더 나은 성능을 얻기 위해 값을 적절하게 늘리고 일정 수준의 일관성을 희생할 수도 있습니다. 🎜
binlog 로그 형식
🎜binlog로그에는 세 가지 형식, 즉 STATMENT, ROW 및 MIXED. 🎜🎜<code>MySQL 5.7.7 이전에는 기본 형식이 STATEMENT이고, MySQL 5.7.7 이후에는 기본값이 ROW입니다. . 로그 형식은 <code>binlog-format을 통해 지정됩니다. 🎜

🎜STATMENT: SQL 문 기반 복제( 문 기반 복제, SBR code> code> ), 데이터를 수정하는 각 SQL 문은 <code>binlog에 기록됩니다. 🎜

🎜ROW: 각 SQL 문의 컨텍스트 정보를 기록하지 않는 행 기반 복제(행 기반 복제, RBR), 어떤 데이터가 수정되었는지만 기록하세요. 🎜

🎜MIXED: STATMENT 및 ROW, MBR

) 기반의 혼합 기반 복제, 일반 복사는 STATEMENT 모드를 사용하여 binlog를 저장하고, STATEMENT 모드에서 복사할 수 없는 작업의 경우 ROW 패턴을 사용합니다. binlog 저장🎜🎜redo 로그🎜
리두 로그가 필요한 이유

🎜우리 모두는 4가지 주요 트랜잭션이 기능 중 하나라는 것을 알고 있습니다. 특히 트랜잭션이 성공적으로 제출되는 한 데이터베이스에 대한 수정 사항은 영구적으로 저장되며 어떤 이유로든 원래 상태로 돌아갈 수 없습니다. 🎜🎜그렇다면 mysql은 어떻게 일관성을 보장합니까? 🎜🎜간단한 방법은 트랜잭션이 커밋될 때마다 수정과 관련된 모든 데이터 페이지를 디스크에 플러시하는 것입니다. 그러나 그렇게 하면 심각한 성능 문제가 발생하며 이는 주로 다음 두 가지 측면에서 반영됩니다. 🎜

Innodb는 페이지 단위로 디스크 상호작용을 수행하기 때문에 트랜잭션은 이때 데이터 페이지에서 몇 바이트만 수정할 수 있습니다. 전체 데이터 페이지가 디스크에 플러시되면 리소스가 낭비됩니다! Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！

一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！

因此mysql设计了redo log，具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

redo log基本概念

redo log包括两部分：一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo logfile)。

mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是MySQL
里经常说到的WAL(Write-Ahead Logging)技术。

在计算机操作系统中，用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。

因此，redo log buffer写入redo logfile实际上是先写入OS Buffer，然后再通过系统调用fsync()将其刷到redo log file
中，过程如下：

mysql支持三种将redo log buffer写入redo log file的时机，可以通过innodb_flush_log_at_trx_commit参数配置，各参数值含义如下：

redo log记录形式

前面说过，redo log实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此redo log实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志。如下图：

同时我们很容易得知，在innodb中，既有redo log需要刷盘，还有数据页也需要刷盘，redo log存在的意义主要就是降低对数据页刷盘的要求 ** 。

在上图中，write pos表示redo log当前记录的LSN(逻辑序列号)位置，check point表示数据页更改记录刷盘后对应redo log所处的LSN(逻辑序列号)位置。

write pos到check point之间的部分是redo log空着的部分，用于记录新的记录；check point到write pos之间是redo log待落盘的数据页更改记录。当write pos追上check point时，会先推动check point向前移动，空出位置再记录新的日志。

启动innodb的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。因为redo log记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志(如binlog)要快很多。

重启innodb时，首先会检查磁盘中数据页的LSN，如果数据页的LSN小于日志中的LSN，则会从checkpoint开始恢复。

还有一种情况，在宕机前正处于checkpoint的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度，此时会出现数据页中记录的LSN大于日志中的LSN，这时超出日志进度的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。

redo log与binlog区别

由binlog和redo log的区别可知：binlog日志只用于归档，只依靠binlog是没有crash-safe
🎜트랜잭션에는 여러 데이터 페이지 수정이 포함될 수 있으며 이러한 데이터 페이지는 물리적으로 연속적이지 않습니다. 임의 IO 쓰기를 사용하는 성능이 너무 낮습니다. 🎜
🎜그래서 mysql은 redo 로그를 설계했습니다. 특히 트랜잭션에 의해 데이터 페이지에 적용된 수정 사항만 기록하므로 성능 문제를 완벽하게 해결할 수 있습니다(비교적으로 파일 크기가 작고 순차 IO임). 🎜🎜
리두 로그의 기본 개념
🎜리두 로그는 두 부분으로 구성됩니다. 하나는 메모리의 로그 버퍼(리두 로그 버퍼)이고, 다른 하나는 디스크의 로그 파일(redo logfile)입니다. 🎜🎜mysql DML 문이 실행될 때마다 해당 레코드는 먼저 리두 로그 버퍼에 기록된 다음 여러 레코드가 기록됩니다. 나중에 작업 기록이 redo 로그 파일에 기록됩니다. 로그를 먼저 작성한 다음 디스크에 쓰는 기술이 MySQL
에서 자주 언급되는 WAL(Write-Ahead Logging) 기술입니다. 🎜🎜컴퓨터 운영 체제에서 사용자 공간(사용자 공간)의 버퍼 데이터는 일반적으로 디스크에 직접 쓸 수 없으며 운영 체제 커널 공간(커널 공간)을 통과해야 합니다. 코드>) 버퍼(OS 버퍼). 🎜🎜그러므로 redo 로그 파일에 쓰는 redo 로그 버퍼는 실제로 OS 버퍼를 먼저 쓴 다음 시스템을 통해 fsync를 호출합니다() redo 로그 파일
에 플래시하세요. 프로세스는 다음과 같습니다. 🎜🎜🎜🎜mysql는 세 가지 유형의 redo 로그 버퍼를 지원합니다. > redo 로그 파일을 작성하는 시점은 innodb_flush_log_at_trx_commit 매개변수를 통해 구성할 수 있습니다. 각 매개변수 값의 의미는 다음과 같습니다. 🎜🎜🎜🎜🎜
redo 로그 기록 형식
🎜앞서 언급했듯이 redo log는 실제로 데이터 페이지의 변경 사항이 기록되며 이러한 변경 기록을 모두 저장할 필요는 없으므로 redo log를 구현합니다. 고정된 크기와 순환 쓰기 방식을 채택합니다. 끝까지 쓰면 처음으로 돌아가서 루프에 로그를 씁니다. 아래와 같이: 🎜🎜 🎜
🎜🎜동시에 innodb에서 redo 로그를 모두 새로 고쳐야 하고 데이터 페이지도 새로 고쳐야 한다는 것을 쉽게 알 수 있습니다. redo log의 주요 목적은 데이터 페이지** 플러시에 대한 요구 사항을 줄이는 것입니다. 🎜🎜위 그림에서 write pos는 현재 redo log에 기록되어 있는 LSN(논리적 시퀀스 번호) 위치를 나타내고, check point는 데이터 페이지 변경 기록이 플러시된 후 해당 <code>redo 로그의 LSN(논리 시퀀스 번호) 위치를 나타냅니다. 🎜🎜write pos와 check point 사이는 새로운 기록을 기록하는 데 사용되는 redo log의 빈 부분입니다. 체크포인트와 write pos 사이에는 디스크에 기록될 redo log 데이터 페이지 변경 기록이 있습니다. write pos가 체크 포인트를 따라잡으면 먼저 체크 포인트를 앞으로 푸시하여 새 로그를 위한 공간을 만듭니다. 🎜🎜innodb를 시작할 때 지난번에 정상적으로 종료되었는지 비정상적으로 종료되었는지에 관계없이 항상 복구 작업이 수행됩니다. redo 로그는 데이터 페이지의 물리적 변경 사항을 기록하므로 복구는 논리 로그(예: binlog)보다 훨씬 빠릅니다. 🎜🎜innodb를 다시 시작하면 먼저 디스크에 있는 데이터 페이지의 LSN을 확인합니다. 로그의 LSN보다 체크포인트부터 복구가 시작됩니다. 🎜🎜종료 전에 체크포인트의 디스크 브러싱 프로세스가 진행되고 있는데, 이때 데이터 페이지의 디스크 브러싱 진행률이 로그 페이지의 디스크 브러싱 진행률을 초과하는 상황도 있습니다. , 데이터 페이지의 기록이 나타납니다. 이 때 로그의 LSN보다 큰 부분은 로그의 진행률을 초과하지 않습니다. 다시 수행해야 합니다. 이는 수행된 작업을 나타내며 다시 수행할 필요가 없기 때문입니다. 🎜
재실행 로그와 binlog의 차이점
🎜🎜🎜 binlog와 redo log의 차이점에서 binlog log를 알 수 있습니다. 보관에만 사용되며 binlog에만 의존하며 충돌 방지 기능이 없습니다. 🎜
그러나 redo 로그만 작동하지 않습니다. redo 로그는 InnoDB에 고유하고 로그의 기록은 작성된 후 덮어쓰기되기 때문입니다. 디스크에. 따라서 데이터베이스를 종료했다가 다시 시작할 때 데이터가 손실되지 않도록 binlog와 redo 로그를 동시에 기록해야 합니다. redo log也不行，因为redo log是InnoDB特有的，且日志上的记录落盘后会被覆盖掉。因此需要binlog和redo log二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。

undo log

数据库事务四大特性中有一个是原子性，具体来说就是原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。

实际上，原子性底层就是通过undo log实现的。undo log主要记录了数据的逻辑变化，比如一条INSERT语句，对应一条DELETE的undo log，对于每个UPDATE语句，对应一条相反的UPDATE的undo log，这样在发生错误时，就能回滚到事务之前的数据状态。

同时，undo log也是MVCC

실행 취소
데이터베이스 트랜잭션의 네 가지 주요 특징 중 하나는 원자성입니다. 특히 원자성은 데이터베이스에 대한 일련의 작업(모두 성공하거나 모두 실패함)을 의미하며 부분 작업은 성공할 수 없습니다. 상황. 🎜🎜실제로 원자성의 최하층은 실행 취소 로그를 통해 달성됩니다. 실행 취소 로그는 주로 데이터의 논리적 변경 사항을 기록합니다. 예를 들어 INSERT 문은 DELETE의 <code>실행 취소 로그에 해당합니다. code> 각 UPDATE 문에는 반대쪽 UPDATE에 해당하는 실행 취소 로그가 있으므로 오류가 발생하면 롤백할 수 있습니다. 이전 거래 상태로 돌아갑니다. 🎜🎜동시에 실행 취소 로그는 MVCC(다중 버전 동시성 제어) 구현의 핵심이기도 합니다. 🎜