XtraBackup을 이용한 InnoDB 증분백업과 복구하기 ( 3 ) 증분백업




Incremental Backup (증분백업)


증분백업이란 바로 이전에 백업했던(그게 풀백업이었던, 증분백업이었던지 간에..)시점부터 현재까지 변경된


내역만 백업하는 방식이다. 설명만으로만 본다면 증분백업은 정말 금방 끝날것같지만 그렇지는 않다.


증분백업도 풀백업과 동일하게 데이터파일을 모두 읽어야 하기 때문이다. 물론 직전 백업의 lsn보다 큰 번호에 


해당하는 것들만 백업하기때문에 풀백업보다는 확실히 시간이 줄고 용량도 적다.




백업 방식


서비스특성이나 관리자 성향에 따라 다 다르겠지만 보통 아래와 같은 방식을 쓴다.


1. 매일매일 풀백업을 한다.

 - 장점 : 속편하다. 설정이 편하다. 복구가 가장 빠르다.

 - 단점 : 새벽에 시작해서 아침에 끝날까? 용량을 너무 먹는다. 1T 데이터를 1주일 저장하면 7T다.

  

2. 풀백업을 한번하고 죽을때까지 증분백업만 한다.

 - 장점 : 용량을 가장 적게 먹는다. 처음 풀백업 외엔 백업시간이 가장 짧다.

 - 단점 : 복구시 오래걸린다. 

 

3. 1주를 단위로 사용량이 가장적은 요일 새벽에 풀백업을 하고 그외 요일은 증분백업을 한다.

 - 장점 : 적은 용량으로 1주일 데이터를 저장할수 있다. 풀백업외에는 백업부하가 적다.

 - 단점 : 설정이 복잡해지고 관리가 귀찮다.

 

SystemV는 일반적인 3번방식을 설명하고자 한다. 사실 가장 장점없고 단점없는 그저그런 방식이랄까...;





LSN 


Log Sequence Number 의 약자로 MySQL 로그파일내에 해당 로그 레코드의 번호값이다. 번호? 순서? 위치? 주소? 암튼..


보통 시점복구나 증분백업등의 관리용으로 사용된다. 1트랜잭션 = 1LSN 은 아니다. 


여러개의 LSN들이 하나의 트랜잭션에 포함되는 구성이 되겠다.





증분백업


증분백업을 위해서는 반드시 이전백업데이터가 있어야 하므로 무조건 풀백업이 한번은 있어야 한다. 


주단위 백업을 설명하기로 했으므로 일요일에 풀백업을하고 그외는 증분백업을 한다고 가정하자.



[일요일] 풀백업


innobackupex --user root --password mysqlrootpw /Backup


풀백업 디렉토리에 xtrabackup_checkpoints 를 보면 풀백업에 대한 lsn 정보가 있다.


[root@localhost 2016-07-28_20-19-45]# cat xtrabackup_checkpoints 

backup_type = full-backuped

from_lsn = 0

to_lsn = 1951426944668

last_lsn = 1951426944668

compact = 0

recover_binlog_info = 0

 

이 풀백업은 0번(from_lsn)부터 1951426944668번(to_lsn)까지 백업된 데이터다.


풀백업이므로 당연히 from_lsn 은 0 이고 to_lsn 은 다음 증분백업의 from_lsn 이 될 것이다.



증분백업은 풀백업 실행문에 --incremental 를 추가해서 이 실행문이 '증분백업이다' 라고 선언해주고


incremental-lsn 에 이전백업(여기서는 풀백업)의 to_lsn 의 값을 할당해주면 된다.



[월요일] 1차증분백업 (풀백업에 대한 증분)

innobackupex --user root --password mysqlrootpw --incremental --incremental-lsn=1951426944668 /Backup



2차 증분백업은 1차증분백업에 대한 증분백업을 해야하므로 1차증분백업 디렉토리에 있는 xtrabackup_checkpoints 의 to_lsn을 이용한다.


[화요일] 2차증분백업 (1차증분백업에 대한 증분)

innobackupex --user root --password mysqlrootpw --incremental --incremental-lsn=2951426944668 /Backup



3차 역시 2차증분백업의 to_lsn을 이용한다.


[수요일] 3차증분백업 (2차증분백업에 대한 증분)

innobackupex --user root --password mysqlrootpw --incremental --incremental-lsn=3951426944668 /Backup

.

..

...

....


이렇게 토요일까지 진행하고 나서 일요일에는 동일한 방식으로 풀백업부터 다시 시작하면 된다.





to_lsn 찾기


grep to_lsn /이전백업의절대경로/xtrabackup_checkpoints | awk '{print $3}'



이게 번거로울 경우 직전백업의 디렉토리경로를 지정해주는 방법도 있다.


--incremental-lsn 옵션 대신에 --incremental-basedir 에 이전백업 디렉토리를 할당해 주면 된다.


innobackupex --user root --password mysqlrootpw --incremental --incremental-basedir=/이전백업의절대경로/ /Backup





증분백업 복구


증분백업의 복구도 풀백업과 동일하게 apply-log 로 로그반영 작업을 해주고 copy-back 으로 실제복구를 하게 된다.


다만 다른점이 있다면 apply-log 로 로그반영시에 --redo-only 옵션을 꼭 같이 써줘야 한다는거다. 



redo-only 


로그반영작업은 백업된 리두로그를 재실행 하면서 백업중에 발생된 트랜잭션에 대한 일관성을 맞추게 되는데 재실행을 마치고 


나서도 커밋되지 않은 트랜잭션이 존재한다면 그런 트랜잭션들은 모두 롤백시켜버린다. 



예를들어 1차 증분백업과 2차 증분백업 두개의 백업에 걸쳐진 트랜잭션은 1차증분백업 로그반영을 하면서 커밋이 안되어


롤백되버렸기 때문에 2차증분백업의 로그를 반영해봐야 해당 데이터는 날릴수 밖에 없다.



"커밋되지 않은 트랜잭션이 남아 있더라도 이후 증분백업의 로그반영 작업을 하면서 해당 트랜잭션이 커밋될 수 있으므로 


롤백작업은 하지마라" 라는 의미로 redo-only 옵션을 써주는 것이다. 



물론 가장 마지막 증분백업의 로그반영시에는 redo-only를 쓸 필요가 없다. 


이후의 백업이 없으므로 어차피 커밋될 여지가 없기 때문이다.




복구상황 가정


위 과정처럼 백업이 매일 새벽에 처리되고 있었으며 오늘이 만약 수요일 업무중인데 데이터가 망실됐다고 가정해보자.


가장 최근 백업데이터는 오늘 새벽 증분백업이다. 이번주 새벽에 풀백업이 있었으므로 일요일(풀백업), 월요일(증분), 화요일(증분), 수요일(증분)을 모두 합치면 오늘 새벽까지의 데이터를 모두 살릴수 있다.


apply-log 로 증분백업을 풀백업에 합쳐주고 copy-back으로 복구시켜보자.

 


apply-log 작업은 풀백업부터 시작해 오래된 데이터부터 진행한다.



1. 일요일 풀백업 로그반영 

innobackupex --apply-log --redo-only /Backup/풀백업디렉토리

이 다음에 증분백업 로그반영이 있으므로 반드시 --redo-only 를 써줘야 한다.



2. 월요일 증분 로그반영

innobackupex --apply-log --redo-only /Backup/풀백업디렉토리 --incremental-dir=/Backup/월요일증분백업디렉토리



3. 화요일 증분 로그반영

innobackupex --apply-log --redo-only /Backup/풀백업디렉토리 --incremental-dir=/Backup/화요일증분백업디렉토리



4. 수요일 증분 로그반영

innobackupex --apply-log /Backup/풀백업디렉토리 --incremental-dir=/Backup/수요일증분백업디렉토리

증분백업의 마지막 로그반영이므로 redo-only는 필요없다.



5. 마지막으로 일요일 풀백업 로그반영 한번더

innobackupex --apply-log /Backup/풀백업디렉토리



6. apply-log 작업으로 모든 증분데이터들이 풀백업에 병합되었으므로 풀백업으로 복구를 하면 된다.


innobackupex --copy-back /Backup/풀백업디렉토리



copy-back 이 끝나고 data_dir 의 소유권과 퍼미션을 맞춰주면 모든 복구작업이 완료된다.








to Top