[Percona] xtrabackup 2.4버전 소개 및 사용방법

■ Percona XtraBackup 소개

Percona에서 만든 백업 유틸리티로 MySQL에 사용되는 온라인 백업입니다. mysqldump처럼 논리적인 백업이 아니라 아예 물리적인 파일을 통째로 특정 디렉토리에 복사하는 방법을 사용합니다. 풀백업, 증분백업, 암호화 백업, 압축백업을 지원합니다. MySQL 엔터프라이즈 라이센스에 포함된 백업 도구의 기능을 모두 제공할 뿐만 아니라 더 유용한 기능들도 제공합니다.

현재 xtrabackup은 현재 2.4, 8.0 2가지를 제공하고 있습니다. 2.4 이하 버전은 EOS되었습니다.

2.4는 MySQL 5.7 이하 버전에 대해 제공하고 있으며 8.0은 MySQL 8.0을 지원합니다. 여기서는 2.4버전으로 설명을 합니다.

2.4 버전은 백업 프로그램명이 xtrabackup과 innobackupex로 2가지로 나뉘어져 있습니다. 특히 innobackupex은 xtrabackup을 symbolic link로 단순히 걸어둔 것입니다. 그러나 이 2가지 프로그램의 사용법이 약간 틀립니다.

원래 innobackupex는 계속 제거된다고 얘기가 나왔지만 본격적으로 제거된 xtrabackup 버전은 8.0에서부터 제거되었습니다.

2.4에서도 xtrabackup으로 사용하면 되지만 아직까지 innobackupex로 설명된 포스팅은 많이 있지만 xtrabackup 프로그램으로 설명된 포스팅은 아직 많이 없어 xtrabackup으로 사용하는 방법의 포스팅합니다.

 

■ Percona XtraBackup 특징

Percona XtraBackup은 InnoDB의 충돌 복구 기능을 기반으로합니다. InnoDB 데이터 파일을 복사하므로 내부적으로 일관성이 없는 데이터가 생성됩니다. 그런 다음 파일에 대해 응급 복구를 수행하여 일관되고 사용 가능한 데이터베이스로 다시 만듭니다.

이것은 InnoDB가 트랜잭션 로그라고 하는 리두 로그를 유지하기 때문에 작동합니다. 여기에는 InnoDB 데이터의 모든 변경에 대한 기록이 있습니다. InnoDB가 시작되면 데이터 파일과 트랜잭션 로그를 검사하고 두 단계를 수행합니다. 커밋된 트랜잭션 로그 항목을 데이터 파일에 적용하고 데이터를 수정하지만 커밋하지 않은 모든 트랜잭션에 대해 실행취소 작업을 수행합니다.

Percona XtraBackup은 시작할 때 로그 시퀀스 번호 (LSN)를 기억한 다음 데이터 파일을 복사하는 방식으로 작동합니다. 이 작업을 수행하는 데 약간의 시간이 걸리므로 파일이 변경되면 다른 시점의 데이터베이스 상태를 반영합니다. 동시에 Percona XtraBackup은 트랜잭션 로그 파일을 감시하는 백그라운드 프로세스를 실행하고 여기에서 변경 사항을 복사합니다. Percona XtraBackup은 트랜잭션 로그가 라운드 로빈 방식으로 작성되고 잠시 후에 재사용 될 수 있기 때문에이를 지속적으로 수행해야합니다. Percona XtraBackup은 실행을 시작한 이후 데이터 파일이 변경 될 때마다 트랜잭션 로그 레코드가 필요합니다.

Percona XtraBackup은 FLUSH TABLES WITH READ LOCK의 경량 대안으로 사용 가능한 경우 백업 잠금을 사용합니다. 이 기능은 Percona Server for MySQL 5.6 이상 버전에서 사용할 수 있습니다. Percona XtraBackup은 이 자동 기능을 사용하여 InnoDB가 아닌 데이터를 복사하여 InnoDB 테이블을 수정하는 DML 쿼리를 차단하지 않도록합니다. 서버에서 백업 잠금을 지원하면 xtrabackup이 InnoDBdata를 먼저 복사하고, 백업용 잠금 테이블을 실행하고 MyISAM 테이블과 .frm 파일을 복사합니다. 이 작업이 완료되면 파일 백업이 시작됩니다.  .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par 및 .opt 파일을 백업합니다.

 

참고 : 잠금은 MyISAM 및 기타  InnoDB가 아닌 테이블에 대해서만 수행이 되며 Percona XtraBackup이 모든 InnoDB / XtraDB 데이터 및 로그 백업을 완료한 후에만 수행됩니다. Percona XtraBackup은 읽기 잠금이 있는 FLUSH 테이블 대신 경량으로 사용 가능한 경우 백업 잠금을 사용합니다. 이 기능은 MySQL 5.6+용 PerconaServer에서 사용할 수 있습니다. Percona XtraBackup은 이를 자동으로 사용하여 InnoDB가 아닌 데이터를 복사하여 InnoDB 테이블을 수정하는 DML 쿼리를 차단하지 않도록합니다.

 

그 후 xtrabackup은 LOCK BINLOG FOR BACKUP을 사용하여 바이너리 로그 위치 또는 Exec_Master_Log_Pos 또는 Exec_Gtid_Set (즉, SHOW MASTER / SLAVE STATUS에 의해보고 된 현재 SQL 스레드 상태 또는 복제 복제본에 해당하는 소스 이진 로그 위치(LOG position))을 변경할 수 있는 모든 작업을 차단합니다. xtrabackup은 REDO 로그 파일 복사를 완료하고 바이너리 로그 위치(Log Position)를 가져옵니다. 이것이 완료되면 xtrabackup은 바이너리 로그와 테이블의 잠금을 해제합니다.

 

마지막으로 바이너리 로그 위치는 STDERR에 출력되고 xtrabackup은 모두 정상이면 0을 반환하여 종료됩니다.

xtrabackup의 STDERR은 파일에 기록되지 않습니다. 파일 (예 : xtrabackup OPTIONS 2> backupout.log)로 리디렉션해야합니다.

또한 백업 디렉토리에 다음 파일을 생성합니다.

 

준비 단계에서 Percona XtraBackup은 복사된 트랜잭션 로그 파일을 사용하여 복사된 데이터 파일에 대해 응급 복구를 수행합니다. 이 작업이 완료되면 데이터베이스를 복원하고 사용할 수 있습니다.

백업된 MyISAM 및 InnoDB 테이블은 준비 (복구) 프로세스 후에 InnoDB의 데이터가 백업이 완료된 지점으로 롤 포워드되고 시작된 지점으로 롤백되지 않기 때문에 결국 서로 일치합니다.이 시점은 FLUSH 테이블과 일치합니다. WITH READ LOCK이 사용되었으므로 MyISAM 데이터와 준비된 InnoDB 데이터가 동기화됩니다.

xtrabackup 및 innobackupex 도구는 모두 앞의 설명에서 언급하지 않은 많은 기능을 제공합니다. 각 도구의 기능은 설명서에 더 자세히 설명되어 있습니다. 간단히 말해서이 도구를 사용하면 데이터 파일 복사, 로그 파일 복사 및 데이터에 로그 적용의 다양한 조합으로 스트리밍 및 증분백업과 같은 작업을 수행할 수 있습니다.

백업 복구

xtrabackup으로 백업을 복원하려면 xtrabackup --copy-back 또는 xtrabackup --move-back 옵션을 사용할 수 있습니다.

xtrabackup은 my.cnf에서 datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir 변수를 읽고 디렉토리가 있는지 확인합니다.

먼저 MyISAM 테이블, 인덱스 등 (.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par 및 .opt 파일)을 복사히고, InnoDB 테이블과 인덱스 다음과 마지막에 로그 파일. 파일을 복사 할 때 파일의 속성을 보존합니다. 백업을 만든 사용자가 소유하므로 데이터베이스 서버를 시작하기 전에 파일의 소유권을 mysql로 ​​변경해야 할 수 있습니다.

또는 xtrabackup --move-back 옵션을 사용하여 백업을 복원할 수 있습니다. 이 옵션은 xtrabackup --copy-back과 유사하지만 파일을 복사하는 대신 대상 위치로 이동한다는 점만 다릅니다. 이 옵션은 백업 파일을 제거하므로주의해서 사용해야합니다. 데이터 파일과 백업 복사본을 모두 저장할 수 있는 디스크 여유 공간이 충분하지 않은 경우에 유용합니다.

 

■ Xtrabackup 설치 방법

소스 설치 혹은 RPM으로 설치하는 방법 2가지를 설명합니다. 편리하신 것으로 설치합니다.

 

▶︎ 소스 설치 방법

• 다운로드 사이트

https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/
2.4 버전중 최신 버전을 소스 혹은 RPM으로 다운로드 받습니다.
소스버전은 /usr/local/src에 받습니다.

$ sudo yum install python3-sphinx flex bison bison-devel automake autoconf libtool cmake libaio libaio-devel  ncurses ncurses-devel zlib zlib-devel libgcrypt libgcrypt-devel libev libev-devel curl libcurl-devel vim-common

 

• 컴파일

컴파일 시간은 대략 40분정도 소요됩니다.

shell> cd /usr/local/src/percona-xtrabackup-2.4.24
shell> mkdir bld
shell> cd bld
shell> cmake .. \
-DWITH_BOOST=/usr/local/src -DDOWNLOAD_BOOST=ON \
-DBUILD_CONFIG=xtrabackup_release -DWITH_MAN_PAGES=OFF -B

shell> make
shell> make install

 

• xtrabackup 타겟 디렉토리 지정

별도 디렉토리를 지정하지 않는 한 아래 디렉토리에 백업합니다.

my.cnf에 설정

[xtrabackup]
target_dir = /data/backups/mysql/

 

▶︎ rpm 설치 방법

• xtrabckup repository 설치

shell> yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

 

• xtrabckup 버전 리스트 확인.

shell> yum list | grep percona

2.4버전으로 설치합니다. 이하 버전은 모두 EOS된 상태입니다.(아래 버전이 없다면 최신 2.4 버전으로 설치합니다.)

shell> yum install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

 

• 별도의 백업 유저 생성시 필요권한

mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cret';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO
'bkpuser'@'localhost'; mysql> FLUSH PRIVILEGES;

 

 

■ xtrabackup 방법

xtrabackup은 2가지 방식의 스텝을 거칩니다. 먼저 온라인 백업을 진행합니다. --prepare 옵션을 한번 수행해 줍니다.

xtrabackup-백업 옵션을 사용하여 백업을 수행 한 후에는 먼저이를 복구하려면 맨 위로 다시 복사해야합니다. 데이터 파일은 프로그램이 실행될 때 서로 다른 시간에 복사되었고이 문제가 발생하는 동안 변경되었을 수 있기 때문에 준비 될 때까지 시점 일관성이 없습니다. 이러한 데이터 파일로 InnoDB를 시작하려고하면 손상을 감지하고 자체적으로 충돌하여 손상된 데이터에서 실행되됩니다.

이 단계로 진입하는것을 방지합니다. xtrabackup --prepare 는 파일을 완벽하게 일관되게 만들어 InnoDB를 실행할 수 있습니다.

그리고 복원 완료시 crash recovery를 방지하고 정상적으로 수행이 됩니다.

 

▶︎ 일반 백업

• 주요 백업 옵션

--backup : 백업 명령

--target-dir=/<directory> : 백업 위치

 

• 백업 방법

shell> xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --backup --target-dir=/mysqlbackup/01

결과

xtrabackup: recognized server arguments: --server-id=1 --datadir=/usr/local/mysql/data --tmpdir=/usr/local/mysql/tmp --innodb_max_dirty_pages_pct=90 --innodb_adaptive_hash_index=1 --innodb_write_io_threads=4 --innodb_read_io_threads=4 --innodb_buffer_pool_size=2G --innodb_file_per_table=1 --innodb_data_home_dir=/usr/local/mysql/data --innodb_data_file_path=ibdata1:100M:autoextend --innodb_log_group_home_dir=/usr/local/mysql/data --innodb_log_buffer_size=60M --innodb_log_file_size=1024M --innodb_log_files_in_group=2 --innodb_flush_log_at_trx_commit=1 --innodb_force_recovery=0 --innodb_doublewrite=1 --log_bin=/usr/local/mysql/logs/binary_log 
xtrabackup: recognized client arguments: --target-dir=/mysqlbackup --user=root --host=localhost --port=3306 --password=* --socket=/usr/local/mysql/tmp/mysqld.sock --backup=1 --target-dir=/mysqlbackup/01 
Can't locate Digest/MD5.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at - line 693.
BEGIN failed--compilation aborted at - line 693.
210312 23:24:38 Connecting to MySQL server host: localhost, user: root, password: set, port: 3306, socket: /usr/local/mysql/tmp/mysqld.sock
Using server version 5.7.32-log
xtrabackup version 2.4.21 based on MySQL server 5.7.32 Linux (x86_64) (revision id: 5988af5)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /usr/local/mysql/data
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = /usr/local/mysql/data
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = /usr/local/mysql/data
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 1073741824
InnoDB: Number of pools: 1
210312 23:24:38 >> log scanned up to (523195003)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 2 for mysql/plugin, old maximum was 0
210312 23:24:39 [01] Copying /usr/local/mysql/data/ibdata1 to /mysqlbackup/01/ibdata1
210312 23:24:39 [01]        ...done
210312 23:24:39 [01] Copying ./mysql/plugin.ibd to /mysqlbackup/01/mysql/plugin.ibd
210312 23:24:39 [01]        ...done
210312 23:24:39 [01] Copying ./mysql/servers.ibd to /mysqlbackup/01/mysql/servers.ibd
210312 23:24:39 [01]        ...done
.....
210312 23:24:41 [01] Copying ./sbtest/sbtest9.frm to /mysqlbackup/01/sbtest/sbtest9.frm
210312 23:24:41 [01]        ...done
210312 23:24:41 Finished backing up non-InnoDB tables and files
210312 23:24:41 [00] Writing /mysqlbackup/01/xtrabackup_binlog_info
210312 23:24:41 [00]        ...done
210312 23:24:41 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '523194994'
xtrabackup: Stopping log copying thread.
.210312 23:24:41 >> log scanned up to (523195003)

210312 23:24:41 Executing UNLOCK TABLES
210312 23:24:41 All tables unlocked
210312 23:24:41 [00] Copying ib_buffer_pool to /mysqlbackup/01/ib_buffer_pool
210312 23:24:41 [00]        ...done
210312 23:24:41 Backup created in directory '/mysqlbackup/01/'
MySQL binlog position: filename 'binary_log.000009', position '139229184'
210312 23:24:41 [00] Writing /mysqlbackup/01/backup-my.cnf
210312 23:24:41 [00]        ...done
210312 23:24:41 [00] Writing /mysqlbackup/01/xtrabackup_info
210312 23:24:41 [00]        ...done
xtrabackup: Transaction log of lsn (523194994) to (523195003) was copied.
210312 23:24:41 completed OK!

 

아래 파일들을 혹인해 보면 로그 위치 정보등이 기록되어 있음.

xtrabackup_binlog_info : 로그파일과 로그 포지션 번호

binary_log.000009       283126734

 

xtrabackup_checkpoints : 백업타입 및 기타 정보들. 백업 타입을 알 수 있음

backup_type = incremental
from_lsn = 523194994
to_lsn = 781654209
last_lsn = 781654218
compact = 0
recover_binlog_info = 0
flushed_lsn = 781654218

 

xtrabackup_info : 서버 정보 및 백업 정보

uuid = ed70d496-8342-11eb-925b-001c42936488
name = 
tool_name = xtrabackup
tool_command = --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password=... --socket=/usr/local/mysql/tmp/mysqld.sock --backup --target-dir=/mysqlbackup/02 --incremental-basedir=/mysqlbackup/01
tool_version = 2.4.21
ibbackup_version = 2.4.21
server_version = 5.7.32-log
start_time = 2021-03-12 23:54:59
end_time = 2021-03-12 23:55:03
lock_time = 0
binlog_pos = filename 'binary_log.000009', position '283126734'
innodb_from_lsn = 523194994
innodb_to_lsn = 781654209
partial = N
incremental = Y
format = file
compact = N
compressed = N
encrypted = N

 

• 백업파일 검증 및 일관성 복원

백업 수행 도중 발생되는 트랜잭션과 깨진 테이블이 있는지,  그리고 로그파일 이상등을 점검.

shell> xtrabackup --prepare --target-dir=/mysqlbackup/base
xtrabackup: recognized server arguments: --innodb_checksum_algorithm=crc32 --innodb_log_checksum_algorithm=strict_crc32 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_log_files_in_group=2 --innodb_log_file_size=1073741824 --innodb_fast_checksum=0 --innodb_page_size=16384 --innodb_log_block_size=512 --innodb_undo_directory=./ --innodb_undo_tablespaces=0 --server-id=1 --redo-log-version=1 
xtrabackup: recognized client arguments: --prepare=1 --target-dir=/mysqlbackup/01 
xtrabackup version 2.4.21 based on MySQL server 5.7.32 Linux (x86_64) (revision id: 5988af5)
xtrabackup: cd to /mysqlbackup/01/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(523194994)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 8388608
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 523194994
InnoDB: Doing recovery: scanned up to log sequence number 523195003 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 139229184, file name binary_log.000009
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.7.32 started; log sequence number 523195003
InnoDB: xtrabackup: Last MySQL binlog file position 139229184, file name binary_log.000009

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 523195022
InnoDB: Number of pools: 1
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 1073741824
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Setting log file ./ib_logfile101 size to 1024 MB
InnoDB: Progress in MB:
 100 200 300 400 500 600 700 800 900 1000
InnoDB: Setting log file ./ib_logfile1 size to 1024 MB
InnoDB: Progress in MB:
 100 200 300 400 500 600 700 800 900 1000
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=523195022
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 523195404
InnoDB: Doing recovery: scanned up to log sequence number 523195413 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 139229184, file name binary_log.000009
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: 5.7.32 started; log sequence number 523195413
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 523195432
210312 23:39:10 completed OK!

 

• 복원

복원할 datadir에서 수행합니다. 자동으로 기존 data 디렉토리에 복원(복사)을 시도합니다.

--copy-back 대신 --move-back 사용시 백업 파일이 기존 datadir로 모두 옮겨집니다.

$ xtrabackup --copy-back --target-dir=/mysqlbackup/base/
$ chown -R mysql:mysql data

 

▶︎ 증분(Incremental) 백업

기존에 풀백업을 한 디렉토리를 이용하여 기존 풀백업에서 변경된 만큼만 증분백업 수행

--incremental-basedir : 최초 풀백업 디렉토리

--target-dir : 백업 디렉토리

증분 백업에 --apply-log-only 옵션을 사용하지 않고 롤백 단계를 중지하면 증분 백업은 쓸모가 없습니다. 트랜잭션이 롤백된 후에는 추가 증분 백업을 적용 할 수 없습니다.

 

• 증분백업방법

- 전체(기본) 백업

shell> xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --backup --target-dir=/mysqlbackup/base
lsn 확인 : xtrabackup_checkpoints
backup_type = full-backuped from_lsn = 0
to_lsn = 1626007
last_lsn = 1626007
compact = 0 recover_binlog_info = 1

 

- 천번째 증분 백업

shell> xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --backup --target-dir=/mysqlbackup/inc01 --incremental-basedir=/mysqlbackup/base

/ data / backups / inc1 / 디렉토리는 이제 ibdata1.delta 및 test / table1.ibd.delta와 같은 델타 파일을 포함해야합니다. 이는 LSN 1626007 이후의 변경 사항을 나타냅니다.이 디렉토리에서 xtrabackup_checkpoints 파일을 살펴보면 다음과 유사한 내용이 표시됩니다.

backup_type = incremental from_lsn = 1626007
to_lsn = 4124244
last_lsn = 4124244 compact = 0 recover_binlog_info = 1

from_lsn은 백업의 시작 LSN이며 증분의 경우 이전 / 기본 백업의 to_lsn (마지막 체크 포인트 인 경우)과 동일해야합니다.

 

- 두번째 증분 백업

shell> xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --backup --target-dir=/mysqlbackup/inc02 --incremental-basedir=/mysqlbackup/inc01

이 폴더에는 xtrabackup_checkpoints도 포함되어 있습니다.

backup_type = incremental from_lsn = 4124244
to_lsn = 6938371
last_lsn = 7110572 compact = 0 recover_binlog_info = 1

 

• 백업파일 검증 및 일관성 복원

- base 백업 준비

기본 백업을 준비하려면 xtrabackup --prepare를 평소와 같이 실행해야하지만 롤백 단계는 방지해야합니다.

shell> xtrabackup --prepare --apply-log-only --target-dir=/mysqlbackup/base
 InnoDB: Shutdown completed; log sequence number 1626007
161011 12:41:04 completed OK!

이 백업은 롤백 단계를 건너 뛴 경우에도 현재 그대로 복원하는 것이 안전합니다. 복원하고 MySQL을 시작하면 InnoDB는 롤백 단계가 수행되지 않았 음을 감지하고 일반적으로 시작시 충돌 복구에 대해 수행하는 것처럼 백그라운드에서 수행합니다. 데이터베이스가 정상적으로 종료되지 않았 음을 알려줍니다.

 

- 첫번째 증분 로그 적용

shell> xtrabackup --prepare --apply-log-only --target-dir=/mysqlbackup/base --incremental-dir=/data/backups/inc1

이는 델타 파일을 / data / backups / base의 파일에 적용하여 증분 백업 시간에 맞춰 롤 포워드합니다. 그런 다음 평소와 같이 리두 로그를 결과에 적용합니다. 최종 데이터는 증분 디렉토리가 아닌 / data / backups / base에 있습니다. 다음과 유사한 출력이 표시되어야합니다.

incremental backup from 1626007 is enabled.
xtrabackup: cd to /mysqlbackup/base
xtrabackup: This target seems to be already prepared with --apply-log-only. xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(4124244) ...
xtrabackup: page size for /tmp/backups/inc1/ibdata1.delta is 16384 bytes Applying /tmp/backups/inc1/ibdata1.delta to ./ibdata1...
...
161011 12:45:56 completed OK!

다시 말하지만 LSN은 첫 번째 증분 백업의 이전 검사에서 본 것과 일치해야합니다. /mysqlbackup/base에서 파일을 복원하는 경우 첫 번째 증분 백업 당시의 데이터베이스 상태가 표시되어야합니다.

 

PXB는 동일한 증분 백업 디렉토리를 사용하여 두 개의 백업 사본을 준비하는 것을 지원하지 않습니다. xtrabackup --prepare를 동일한 증가 백업 디렉토리 (-incremental-dir의 값)로 두 번 이상 실행하면 안됩니다.

 

- 두번째 증분 로그 적용

두 번째 증분 백업을 준비하는 과정은 비슷합니다. (수정 된) 기본 백업에 델타를 적용하면 데이터를 두 번째 증분 백업 시점으로 롤 포워드합니다.

shell> xtrabackup --prepare --target-dir=/mysqlbackup/base --incremental-dir=/mysqlbackup/inc2

 

shell> xtrabackup --apply-log-only는 마지막 증분을 제외한 모든 증분을 병합할 때 사용해야합니다. 그렇기 때문에 이전 행에 xtrabackup --apply-log-only 옵션이 포함되어 있지 않습니다. xtrabackup --apply-log-only가 마지막 단계에서 사용 된 경우에도 백업은 여전히 일관성이 있지만이 경우 서버는 롤백 단계를 수행합니다.

 

• 복원

복원할 datadir에서 수행합니다. 자동으로 기존 data 디렉토리에 복원(복사)을 시도합니다. --copy-back 대신 --move-back 사용시 백업 파일이 기존 datadir로 모두 옮겨집니다.

shell> xtrabackup --copy-back --target-dir=/mysqlbackup/base/
shell> chown -R mysql:mysql data

 

▶︎ 압축백업

• 파일을 압축하여 백업합니다.

1. 일반압축 백업

$ xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --compress --backup --target-dir=/mysqlbackup/compress

 

2. 병렬 스레드 백업

지정한 스레드만큼 스레드를 생성하여 백업

shell> xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --compress --compress-threads=4 --backup --target-dir=/mysqlbackup/compress

 

• 압축 해제

압축되어 있던 기존 파일을 삭제합니다. 그리고 기존 data 디렉토리에 복원을 시도합니다.

--copy-back 대신 --move-back 사용시 백업 파일이 기존 datadir로 모두 옮겨집니다.

 

- 압축해제.

--remove-original는 기존 압축파일 제거.

$ xtrabackup --decompress --remove-original --decompress-threads=4 --target-dir=/mysqlbackup/compress/

 

- 백업파일 검증 및 일관성 복원

$ xtrabackup --prepare --target-dir=/data/compressed/

 

• 복원

--copy-back 대신 --move-back 사용시 백업 파일이 기존 datadir로 모두 옮겨집니다.

shell> xtrabackup --copy-back --target-dir=/mysqlbackup/compress/

 

▶︎ 암호화 백업

백업파일을 암호화해서 백업하는 방법입니다. 암호 백업은 다음과 같은 주요 옵션이 있습니다.

--encrypt=ALGORITHM : 암호화 알고리즘입니다. AES128, AES192, AES256 방식이 있습니다.

--encrypt-key=ENCRYPTION_KEY : 암호화할 키 입니다.

--encrypt-key-file=KEYFILE : 암호화 키가 저장되어 있는 파일을 이용합니다.

암호화를 이용하여 백업하는 방법은 2가지 방식이 있습니다. 키를 직업 이용하거나 생성된 키를 특정 파일에 저장후 사용합니다.

한번 생성한 키는 잃어버릴 시 다시 사용할 수 없으므로 가능하면 생성키를 파일에 저장하여 보관합니다.

 

• 암호화 키 생성

- 키 생성

shell> openssl rand -base64 24
tJa4R62mfQ7Fg2SPl+QD81RQiheaPaKA

 

- 키 파일 생성

키 파일을 만드는 데 사용되는 텍스트 편집기에 따라 일부 경우 텍스트 파일에 CRLF가 포함되어 있으면 키 크기가 커져서 유효하지 않게됩니다.

이를 회피하는 방법은 아래와 같은 방법으로 키 파일을 만드는 것입니다.

shell> echo -n "tJa4R62mfQ7Fg2SPl+QD81RQiheaPaKA" > /mysqlbackup/keyfile

 

 

• 암호화키를 이용하여 암호화 백업

파일명 끝에 확장자로 xbcrypt가 붙습니다.

- 키를 이용하는 방법

shell> xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --backup --target-dir=/mysqlbackup/encryption --encrypt=AES256 --encrypt-key="tJa4R62mfQ7Fg2SPl+QD81RQiheaPaKA"

 

- 키 파일을 이용하는 방법

shell> xtrabackup --defaults-file=/etc/my.cnf --user=root --host=localhost --port=3306 --password='admin1234' --socket=/usr/local/mysql/tmp/mysqld.sock --backup --target-dir=/mysqlbackup/encryption --encrypt=AES256 --encrypt-key-file=/mysqlbackup/keyfile

 

• 복호화 방법

참고사항 : 복호화를 하게 되면 암호화된 파일을 풀면서 원래 파일이 생서됩니다. 이때 기존 암호화된 파일이 남게 됩니다.

키를 이용하는 방법

shell> xtrabackup --decrypt=AES256 --encrypt-key="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs" --target-dir=/mysqlbackup/encryption

키 파일을 이용하는 방법

shell> xtrabackup --decrypt=AES256 --encrypt-key-file=/mysqlbackup/keyfile --target-dir=/mysqlbackup/encryption

복호화하면서 기존 암호화 파일 제거.

xbcrypt 확장자 파일이 제거됩니다.

shell> xtrabackup --decrypt=AES256 --encrypt-key-file=/mysqlbackup/keyfile --target-dir=/mysqlbackup/encryption --remove-original

 

틀린키로 복호화시 에러 메세지

xbcrypt:xb_crypt_decrypt invalid plaintext hash. Wrong encrytion key specified?
decrypt: failed to decrypt chunk.
xbcrypt failed to decrypt: can't write to output.
Error: decrypt and decompress thread 0 failed.

 

- 백업파일 검증 및 일관성 복원

shell> xtrabackup --prepare --target-dir=/data/backups/

 

- 복원

--copy-back 대신 --move-back 사용시 백업 파일이 기존 datadir로 모두 옮겨집니다.

shell> xtrabackup --copy-back --target-dir=/data/backups/

 

 

■ 기타 옵션

위에 원하는 형식으로 백업하면서 추가적인 옵션을 지정할 수 있습니다. 데이터베이스, 테이블에 대해 필터링이 가능합니다.

그외 replication 상에서 백업, 갈레라 클러스터 환경에서도 백업이 가능합니다.

 

--tables=name

테이블 이름에 대한 정규식으로 필터링.

 

--tables-file=name

파일의 정확한 database.table 이름 목록으로 필터링.

 

--databases=name

데이터베이스 목록으로 필터링.

 

 

--databases-file=name

파일의 데이터베이스 목록으로 필터링. 

 

--tables-exclude=name 

테이블 이름을 정규 표현식으로 필터링합니다. --tables와 동일한 방식으로 작동하지만 일치하는 이름은 백업에서 제외됩니다. 이 옵션은 --tables보다 우선 순위가 높습니다.

 

 

--databases-exclude=name 

이름을 기준으로 데이터베이스 제외, --databases와 동일한 방식으로 작동하지만 일치하는 이름은 백업에서 제외됩니다. 이 옵션은 --databases보다 우선 순위가 높습니다.

 

--no-lock 옵션.

이 옵션을 사용하여 "FLUSH TABLES WITH READ LOCK"으로 테이블 잠금을 비활성화합니다.

모든 테이블이 InnoDB이고 백업의 바이너리 로그 위치에 대해 신경 쓰지 않는 경우에만 사용하십시오.

실행중인 DDL 문이 있거나 InnoDB가 아닌 테이블 (mysql 데이터베이스의 시스템 MyISAM 테이블 포함)에서 업데이트가 발생하는 경우이 옵션을 사용하면 안됩니다. 그렇지 않으면 백업이 일관되지 않을 수 있습니다.

백업이 잠금을 획득하지 못하여 --no-lock을 사용하려는 경우 이는 들어오는 복제 이벤트로 인해 잠금이 성공하지 못하기 때문일 수 있습니다.

--safe-slave-backup을 사용하여 복제 슬레이브 스레드를 일시적으로 중지하십시오. 이렇게하면 백업이 성공하는 데 도움이 될 수 있으며이 옵션을 사용할 필요가 없습니다.

 

--galera-info

이 옵션은 백업시 로컬 노드 상태를 포함하는 xtrabackup_galera_info 파일을 생성합니다.

Percona-XtraDB-Cluster의 백업을 수행 할 때 옵션을 사용해야합니다.

백업 잠금을 사용하여 백업을 만들면 효과가 없습니다.

 

--slave-info

이 옵션은 복제 슬레이브 서버를 백업할 때 유용합니다.

이진 로그 위치와 마스터 서버의 이름을 인쇄합니다.

또한 이 정보를 "CHANGE MASTER"명령으로 "xtrabackup_slave_info"파일에 기록합니다.

이 마스터의 새 슬레이브는 이 백업에서 슬레이브 서버를 시작하고 "xtrabackup_slave_info"파일에 저장된 바이너리 로그 위치로 "CHANGE MASTER"명령을 실행하여 설정할 수 있습니다.

 

--safe-slave-backup

슬레이브 SQL 스레드를 중지하고 "SHOW STATUS"의 Slave_open_temp_tables가 0이 될 때까지 백업 시작을 기다립니다.

열린 임시 테이블이 없으면 백업이 수행되고 그렇지 않으면 열린 임시 테이블이 없을때까지 SQL 스레드가 시작되고 중지됩니다.

--safe-slave-backup-timeout초 후에 Slave_open_temp_tables가 0이 되지 않으면 백업이 실패합니다.

백업이 완료되면 슬레이브 SQL스레드가 다시 시작됩니다.

 

--no-backup-locks

이 옵션은 백업 단계에서 FLUSH TABLES WITH READ LOCK 대신 백업 잠금을 사용해야하는지 여부를 제어합니다.

이 옵션은 서버에서 백업 잠금을 지원하지 않는 경우 효과가 없습니다.

이 옵션은 기본적으로 활성화되어 있으며 --no-backup-locks로 비활성화합니다.

 

--remove-original

암호 해독 및 압축 해제후 .qp및 .xbcrypt 파일을 제거합니다.