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

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

Full Backup

기본 풀백업은 아래처럼 간단하게 할 수 있다.

[root@localhost ~]# innobackupex --user root --password mysqlrootpw /Backup

160609 16:46:54 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.

           At the end of a successful backup run innobackupex

           prints "completed OK!".

160609 16:46:54  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/tmp/mysql.sock' as 'root'  (using password: YES).

160609 16:46:54  version_check Connected to MySQL server

160609 16:46:54  version_check Executing a version check against the server...

160609 16:46:54  version_check Done.

..

..

..

160609 16:47:41 [00] Writing backup-my.cnf

160609 16:47:41 [00]        ...done

160609 16:47:41 [00] Writing xtrabackup_info

160609 16:47:41 [00]        ...done

xtrabackup: Transaction log of lsn (1667732673) to (1667732673) was copied.

160609 16:47:41 completed OK!

[root@localhost ~]# 

가장 밑줄에 있는 completed OK! 가 떨어지면 백업이 정상 종료된거다.

내부적인 실행순서는 아래와 같다.

1. ibdata1 (시스템 테이블스페이스) 카피

2. InnoDB  파일 카피 (.ibd)

3. FLUSH NO_WRITE_TO_BINLOG TABLES 실행

4. FLUSH TABLES WITH READ LOCK 실행

5. non-InnoDB  파일카피 (.MYI, .MYD, .FRM)

6. UNLOCK TABLES 실행

7. backup-my.cnf 생성

8. xtrabackup_info 생성

9. 종료

/Backup 디렉토리 안에 현재 날짜/시간으로 디렉토리가 만들어지고 그 안에 아래와 같이 백업이 된다.

[root@localhost 2016-06-09_16-46-54]# ll

합계 1024060

-rw-r----- 1 root root        421 2016-06-09 16:47 backup-my.cnf

-rw-r----- 1 root root 1048576000 2016-06-09 16:47 ibdata1

drwxr-x--- 2 root root       4096 2016-06-09 16:47 mysql

drwxr-x--- 2 root root       4096 2016-06-09 16:47 performance_schema

-rw-r----- 1 root root        119 2016-06-09 16:47 xtrabackup_checkpoints

-rw-r----- 1 root root        435 2016-06-09 16:47 xtrabackup_info

-rw-r----- 1 root root       2560 2016-06-09 16:47 xtrabackup_logfile

backup-my.cnf : 백업&복구에 필요한 몇가지 옵션이 저장되어 있다. my.cnf자체를 백업한게 아니다.

xtrabackup_checkpoints : 아래와 같은 내용을 담고 있다. 백업타입과 lsn 정보등. 

backup_type = full-backuped

from_lsn = 0

to_lsn = 1667732673

last_lsn = 1667732673

compact = 0

recover_binlog_info = 0

xtrabackup_info : 백업 실행시의 각종 상태(백업시간,사용한 옵션,버전정보등등..)를 저장.

백업시 추가적으로 사용 할 수 있는 옵션들

--host : 원격 백업일때 디비서버 아이피를 적어주면 된다. 안쓰면 기본이 localhost

--port : 안쓰면 기본이 3306

--defaults-file : 안쓰면 기본이 /etc/my.cnf 

--backup : 안쓰면 기본이 --backup, --apply-log 나 --copy-back 등을 쓸수 있음.

--no-timestamp : 날짜/시간으로 된 디렉토리를 생성하지 않는다. 지정한 경로에 바로 백업파일을 생성한다.

그리고 성능 개선을 위해...

--parallel : .ibd 데이터 파일 복사시 병렬로 처리한다. --parallel=4

InnoDB가 아니거나 innodb_file_per_table 을 사용하지 않을때는 당연히 성능향상은 없다.

병렬처리 옵션을 줘도 MyISAM 이나 InnoDB의 .frm 파일은 병렬처리가 안된다.

--compress_threads : 압축백업시 압축수행하는 쓰레드 수 지정.

로그반영

이전글에서 설명했듯 백업만 완료된 데이터는 inconsistent 하기 때문에 이 데이터로는 복구를 할 수 없다.

그렇기 때문에 꼭 백업된 리두로그를 백업된 데이터파일에 반영해줘야한다.

로그반영은 아래처럼 --apply-log 옵션과 함께 백업된 디렉토리를 지정해주면 된다.

[root@localhost ~]# innobackupex --apply-log /Backup/2016-06-09_16-46-54

160609 21:06:30 innobackupex: Starting the apply-log operation

IMPORTANT: Please check that the apply-log run completes successfully.

           At the end of a successful apply-log run innobackupex

           prints "completed OK!".

innobackupex version 2.4.3 based on MySQL server 5.7.11 Linux (x86_64) (revision id: 6a46905)

xtrabackup: cd to /Backup/2016-06-09_16-46-54

xtrabackup: This target seems to be not prepared yet.

InnoDB: Number of pools: 1

xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(1667732763)

xtrabackup: using the following InnoDB configuration for recovery:

..

..

..

..

InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.

InnoDB: 32 non-redo rollback segment(s) are active.

InnoDB: page_cleaner: 1000ms intended loop took 5030ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)

InnoDB: 5.7.11 started; log sequence number 1667736597

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

InnoDB: FTS optimize thread exiting.

InnoDB: Starting shutdown...

InnoDB: Shutdown completed; log sequence number 1667738299

160609 21:06:39 completed OK!

[root@localhost ~]# 

백업때와 마찬가지로 가장 밑줄에 있는 completed OK! 가 떨어지면 로그반영로이 정상 종료된거다.

[root@localhost 2016-06-09_16-46-54]# ll

합계 1568824

-rw-r----- 1 root root        421 2016-06-09 20:27 backup-my.cnf

-rw-r----- 1 root root  134217728 2016-06-09 21:06 ib_logfile0

-rw-r----- 1 root root  134217728 2016-06-09 21:06 ib_logfile1

-rw-r----- 1 root root  134217728 2016-06-09 21:06 ib_logfile2

-rw-r----- 1 root root  134217728 2016-06-09 21:06 ib_logfile3

-rw-r----- 1 root root 1048576000 2016-06-09 21:06 ibdata1

-rw-r----- 1 root root   12582912 2016-06-09 21:06 ibtmp1

drwxr-x--- 2 root root       4096 2016-06-09 20:27 mysql

drwxr-x--- 2 root root       4096 2016-06-09 20:27 performance_schema

-rw-r----- 1 root root        119 2016-06-09 21:06 xtrabackup_checkpoints

-rw-r----- 1 root root        435 2016-06-09 20:27 xtrabackup_info

-rw-r----- 1 root root    8388608 2016-06-09 21:06 xtrabackup_logfile

이제 이 파일들은 완전히 consistent 한 데이터가 되었고 이 데이터들로 복구를 할 수 있게 되었다.

로그반영시 추가할수 있는 옵션

로그반영 작업을 좀 더 빠르게 하기위해 --use-memory 옵션을 사용할 수 있다.

지정하지 않으면 기본값이 100M 로 셋팅되는데 로그반영은 보통 복구 직전에 진행하기에 디비도 내려간 상태이므로

메모리 여유량이 충분할 것이다. 넉넉히 셋팅해주자. 

[root@localhost ~]# innobackup --apply-log --use-memory=4G /Backup/2016-06-09_16-46-54

복구

로그반영까지 완료된 상태에서 복구는 아주 간단하다. 실행옵션 3가지중 --copy-back 을 써주면 된다. 

다시 한번 알아보는 실행옵션 3가지

--backup      : 백업할때 사용. 생략가능

--apply-log  : 로그반영시 사용

--copy-back : 복구시 사용

복구시 주의사항

- 복구전에 datadir 디렉토리는 비어있어야 한다. --copy-back 은 기존파일을 덮어쓰지 못한다. 

  datadir 이 비어있지 않을때는 -force-non-empty-directories 옵션을 이용할 순 있지만 기존 파일을 덮어쓰는 무모한 도전은

  의미가 없다. mv 를 이용해 기존 datadir 이름을 바꾸고 mkdir 로 새로 생성해주자.

- partial backup을 임포팅하는 작업이 아니라면 반드시 디비는 내려간 상태여야 한다.

- 사실 로그반영이 완료된 데이터는 이미 consistent 하므로 --copy-back 을 이용하지 않고 백업디렉토리를 그대로 datadir 로 옮겨도 무방하다. 하지만 운영에 필요없는 파일들도 같이 들어가므로 특별한 이유가 아니라면 정석대로 --copy-back을 사용하도록 하자.

[root@localhost ~]# innobackupex --copy-back /Backup/2016-06-09_16-46-54

역시 위 작업들과 동일하게 innobackupex: completed OK! 가 떨어지면 정상종료 된것이다.

내부적인 복구 과정은 아래와 같다.

1. 데이터파일(.ibd)과 메타데이터(.frm) 카피

2. 시스템테이블 스페이스(iddata1) 카피

3. 언두테이블 스페이스 (따로 있지 않다면 생략)

4. 리두로그(ib_logfile0..) 카피

복구된 데이터의 퍼미션을 확인해보고 mysql 권한이 아니라면 반드시 수정하고 디비를 올려보자.

[root@localhost ~]# chown mysql. /app/mariadb/data -R

[root@localhost ~]# /app/mariadb/bin/mysqld_safe &

[1] 25206

[root@localhost ~]# 160610 17:21:07 mysqld_safe Logging to '/app/mariadb/data/error-log.err'.

/app/mariadb/data/mariaDB.pid

160620 17:21:07 mysqld_safe Starting mysqld daemon with databases from /app/mariadb/data

[root@localhost ~]# 

이상없이 데몬이 잘올라온것을 확인할 수 있다. 예상 못했던 문제가 있을수 있으므로 errorlog 를 꼭 확인하도록 한다.

풀백업정리

풀백업 

$ innobackupex /data/backups

/data/backups에 오늘날짜 디렉토리에 백업파일 생성

$ innobackupex --no-timestamp /data/backups

/data/backups에 백업파일 생성

로그반영

$ innobackupex --use-memory=4G --apply-log /data/backups/2016-03-01_01-00-00

메모리 4기가 할당해 /data/backups/2016-03-01_01-00-00 백업디렉토리에 대한 로그반영

복구

$ innobackupex --copy-back /data/backups/2016-03-01_01-00-00

백업데이터 /data/backups/2016-03-01_01-00-00 를 datadir 로 복구. datadir 경로는 당연히 my.cnf 참조