MySQL Redo Log 알아보기

 

- 목차

 

함께 보면 좋은 글

https://westlife0615.tistory.com/16

MySQL Page 알아보기

 

소개.

MySQL 의 Redo Log 는 Write Query 에 해당하는 데이터의 변경을 저장합니다. 
Insert, Update, Delete 요청의 타겟이 되는 Rows 들의 변경사항을 기록합니다. 
이러한 하나하나의 기록들을 Redo Log Entry 라고 하구요. 

Redo Log Entry 는 아래와 같이 구성됩니다. 


< INSERT 타입의 Redo Log Entry >

LSN: 123456
Transaction ID: 789
Index: customer_date_idx (composite index on customer_id and order_date)
Operation: INSERT
Before Image (Index): None (as this is a new entry)
After Image (Index): (customer_id=101, order_date='2023-10-20')

< UPDATE 타입의 Redo Log Entry >

LSN: 123456
Transaction ID: 789
Page ID: 456
Operation: UPDATE
Before Image:
   Row (employee_id=101, first_name='John', last_name='Doe', salary=50000.00)
After Image:
   Row (employee_id=101, first_name='John', last_name='Doe', salary=55000.00)

< DELETE 타입의 Redo Log Entry >

LSN: 123456
Transaction ID: 789
Operation: DELETE
Table: 'test_table'
Affected Rows:
  - Row with Primary Key Value: 1
  - Row with Primary Key Value: 2
  - ...
  - Row with Primary Key Value: 10

사실 Redo Log 는 Text 형식이 아닌 Binary 형식의 데이터 파일입니다. 
인간친화적이지 않기 때문에 쉽게 읽을 수 있는 형식은 아니지만, 
위와 같은 구성을 가진다고 생각하시면 좋을 것 같습니다. 

이러한 Redo Log Entry 들이 쌓여서 어떤 데이터들이 변경되었는지를 MySQL 은 파악할 수 있게 됩니다. 
Redo Log 의 쓰임새는 Recovery 단계에서 사용됩니다. 
Sudden Crash 라고 하죠.
MySQL 서버가 갑자기 다운되는 경우에 복원 작업이 필요한데요. 
이러한 케이스에서 Redo Log 가 사용됩니다. 

이어지는 내용에서 Redo Log 에 대해서 상세히 알아보도록 하겠습니다. 

Redo Log 는 In-Memory 구조인가 On-Disk 구조인가?  

Redo Log 는 MySQL 에서 어떻게 존재하는지 알아보도록 하겠습니다. 
Redo Log 는 In-Memory 그리고 On-Disk 모두에서 존재합니다. 
메모리에서는 Redo Log Entry 를 저장하는 버퍼로써 동작하구요. 
Transaction 이 commit 되는 시점에 메모리의 Redo Log 는 Disk 로 Flush 됩니다. 

네트워크를 통해서 여러 Write Query 들이 MySQL 에 발을 들이게 됩니다. 
Insert, Update, Delete 쿼리들이 MySQL 로 진입하여 
Query Parser 를 포함한 여러 단계를 거쳐 Redo Log Entry 가 됩니다. 
Redo Log Entry 는 위에서 설명한 구조를 가집니다. 

< Redo Log Entry (operation:insert) >

insert into test_user(name, age) values('John', 30);

--------------------------------------------------------

LSN: 123456
Transaction ID: 789
Operation: INSERT
Table: 'test_user'
Row:
  - id: 1
  - name: 'John'
  - age: 30

Row 를 변경하는 쿼리가 Redo Log Entry 라는 데이터로 치환되어
In-Memory 상에서 존재하는 Redo Log 에 저장됩니다. 

그리고 해당 Write Query 들의 Transaction 이 완료되면,
In-Memory 의 Redo Log 에 존재하는 여러 Entry 들은 On-Disk 의 Redo Log 로 Flush 됩니다. 
이러한 과정으로 Redo Log 에 데이터들이 생성됩니다. 

 

 

Recovery.

만약 MySQL 에 sudden crash 되었다고 가정하겠습니다. 
이렇게 되면 MySQL 은 Recovery 를 시도해야하는데요. 
Recovery 는 두 가지의 기본적인 데이터들이 필요합니다. 

1. 최근의 Checkpoint 상태의 데이터
2. 최근의 Checkpoint 이후의 데이터 변경 기록

** Checkpoint ** 

checkpoint 는 메모리의 버퍼에 존재하는 데이터들이 Disk 로 Flush 되는 작업을 의미합니다. 
Buffer Pool 에 존재하는 여러 Page 들과 Redo Log 에 기록된 Entry 들이 Disk 로 저장됩니다. 
Checkpoint 를 기존으로 데이터들이 영구적으로 저장되게 됩니다.

 
이를 쉽게 설명하면, 
1 부터 100 까지 데이터를 저장해야한다고 생각하겠습니다. 
저장하는 방식은 다양한데요.
1. Empty 상태에서 1 ~ 100 까지 저장
2. 1이 저장된 상태에서 2 ~ 100 까지 저장
3. 1 ~ 50 까지 저장된 상태에서 51 ~ 100 까지 저장
등의 방식이 있습니다. 

Recovery 는 위의 방식처럼 
Disk 의 데이터들이 마지막 Checkpoint 의 상태이며, 
Redo Log 에는 마지막 Checkpoint 부터 현재까지의 데이터 변경 기록들이 저장되어 있습니다. 
따라서 Recovery 단계에서 Redo Log 의 Entry 들을 하나씩 적용하여 
Sudden Crash 시점의 상태로 복원하게 됩니다. 

Redo Log Entry.

 

Redo Log Entry 에 대해서 알아보도록 하겠습니다. 
Redo Log 는 Write Query 의 대상이 되는 데이터들의 변경 기록이 저장된다고 말씀드렸습니다. 
Write Query 의 종류로는 Insert, Update, Delete 가 있으며, 
이들은 Table 범위의 변경 사항입니다. 

그리고 Index 또한 Redo Log Entry 의 대상입니다. 
Write Query 를 통해서 Index 또한 변경되기 때문이죠. 

아래와 같은 테이블이 존재한다고 가정하겠습니다. 
테이블의 이름은 test_user 이구요. 
primary key 와 city colume 의 index 가 존재합니다.
 
< test_user table >

create table test_user (
	id int not null auto_increment, 
	city varchar(64) not null, 
	name varchar(64) not null,
	primary key(id),
	key city_index (city)
) engine=innodb;

test_user 테이블의 Write Query 와 상응하는 Redo Log Entry 에 대해서 알아보겠습니다. 

 

<Insert Query For Row and Index.>

insert into test_user(city, name) values('Seoul', 'Andy');

LSN: 1
Transaction ID: 1
Operation: INSERT
Table: 'test_user'
Row:
  - id Value: 1
  - name: 'Andy'
  - city: 'Seoul'

LSN: 2
Transaction ID: 1
Operation: INDEX
Table: 'test_user'
Index: 'city_index'
Key Value: 'Seoul'

 

하나의 Row 에 대한 생성 Entry 와 Index 에 대한 Entry 가 생성됩니다. 
LSN 는 Long Sequence Number 의 약자로 Entry 의 식별값입니다. 
LSN 는 incremental 방식으로 생성됩니다. 
그리고 Transaction ID 또한 추가됩니다. 
Transaction 을 기준으로 Redo Log 는 In-Memory 에서 On-Disk 로 Flush 됩니다. 

<Update Query For Row.>

update test_user set name = 'Chris' where name = 'Andy';

LSN: 3
Transaction ID: 2
Operation: UPDATE
Table: 'test_user'
Old Value : 'Andy'
New Value : 'Chris'

하나의 Row 에 대한 수정 Entry 가 생성됩니다. 
Indexing 된 Column 이 아니기 때문에 Row 에 대한 Entry 만 생성됩니다. 
 

<Update Query For Row and Index.>

 

update test_user set city = 'Busan' where city = 'Seoul';

LSN: 4
Transaction ID: 3
Operation: UPDATE
Table: 'test_user'
Old Value : 'Seoul'
New Value : 'Busan'

LSN: 5
Transaction ID: 3
Operation: INDEX
Table: 'test_user'
Old Value : 'Seoul'
New Value : 'Busan'

하나의 Row 에 대한 수정 Entry 와 Index 에 대한 수정 Entry 가 생성됩니다. 


참고로 위에서 설명하는 Entry 에 대한 세부적인 내용은 정확하진 않습니다. 
다만, Write Query 의 Redo Log Entry 로의 변환이 이런 식으로 수행된다고만 이해해주시기 바랍니다. 

 
 

Redo Log File 은 어디에 위치하는가?

Redo Log File 이 저장되는 위치에 대해서 알아보겠습니다. 

"innodb_log_group_home_dir" 의 system variable 은 Redo Log File 들이 저장되는 위치정보를 가지는 환경변수입니다. 
innodb_log_group_home_dir 은 절대 경로를 반환하는 경우가 있고, 상대 경로를 반환하는 경우가 있습니다.

정확한 위치는 아래 쿼리를 통해서 확인가능합니다. 
 

show variables like '%innodb_log_group_home_dir%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| innodb_log_group_home_dir | ./    |
+---------------------------+-------+

Or

+---------------------------+-------------------+
| Variable_name             | Value             |
+---------------------------+-------------------+
| innodb_log_group_home_dir | /var/lib/mysql/   |
+---------------------------+-------------------+

 
만약 상대경로의 위치정보가 반환된다면, 아래의 쿼리를 통해서 Current Directory 를 찾아야합니다. 

show variables like '%datadir%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+

그리고 아래의 command 로 ib_logfile 로 시작하는 Redo Log File 들을 찾을 수 있습니다. 

ls -al /var/lib/mysql | grep ib_logfile
-rw-r----- 1 mysql mysql 50331648 Oct 09 06:32 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Oct 08 22:45 ib_logfile1

Redo Log File 은 innodb_log_files_in_group 값으로 설정한 갯수만큼 관리할 수 있습니다. 
일반적으로 2개의 Redo Log File 을 관리하게 됩니다. 

show variables like 'innodb_log_files_in_group';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| innodb_log_files_in_group | 2     |
+---------------------------+-------+

 
 

정리하며...

 
Redo Log 는 Write Query 로 인해 발생하는 변경 사항들을 기록하는 버퍼이자 파일입니다. 
Redo Log 는 메모리와 디스크 영역 모두에서 존재하며, 
메모리에선 버퍼로써 동작하고 디스크에선 영구적인 파일로써 존재합니다. 

Redo Log 의 주 목적은 Sudden Crash 로부터 Recovery 에 있습니다. 
Sudden Crash 로 인해 MySQL 이 죽게 되면, 
필연적으로 Disk 의 상태는 마지막 Checkpoint 의 상태가 됩니다. 
그리고 Recovery 를 위해서 마지막 Checkpoint 이후의 Redo Log 의 기록들을 새롭게 Write 합니다. 
이렇게함으로써 Recovery 가 동작하게 되죠. 

Undo Log, Buffer Pool 등과 함께 Redo Log 는 MySQL 의 효율성과 안정성을 위해서 사용됩니다. 
이번 글이 여러분에게 작은 도움이 되었으면 좋겠습니다.