'MySQL/Xtrabackup' 카테고리의 글 목록

MySQL/Xtrabackup

[Xtrabackup] innobackupex Full backup 복구 (MySQL Clone DB???) 2016.09.20 2
[Xtrabackup] Backup 방법2 (추가 full backup) 2016.09.20
[Xtrabackup] Backup 방법 ( Full / Incremental) 2016.09.13 2
[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32 2016.09.08

[Xtrabackup] innobackupex Full backup 복구 (MySQL Clone DB???)

2016. 9. 20. 17:46

지금까지 백업을 진행 했다면,

반대로 복구가 필요한 경우가 생긴다.

대부분의 블로그나 심지어 Percona 사이트에서도 아래와 같이 복구를 진행 한다.

아래는 복구 관련 메뉴얼이다.

https://www.percona.com/doc/percona-xtrabackup/2.3/innobackupex/incremental_backups_innobackupex.html

innobackupex --copy-back BASE-DIR

BASE-DIR 는 백업을 진행한 폴더를 뜻한다.

즉, 백업을 진행하고 나면 백업 폴더내 2016-09-20_11-40-34와 같은 폴더가 생긴다.(날짜_시간으로 폴더가 생김)

이렇게 하면 my.cnf 내 BASEDIR 에 있는 내용을 참고하여 해당 폴더에 복구를 진행하게 된다.

하지만, 문제는 BASEDIR 에 해당하는 디렉토리가 비어 있어야 한다. 비어 있지 않으면 에러가 발생한다.

160920 15:33:41 innobackupex: Starting the copy-back operation

IMPORTANT: Please check that the copy-back run completes successfully.

At the end of a successful copy-back run innobackupex

prints "completed OK!".

innobackupex version 2.4.4 based on MySQL server 5.7.13 Linux (x86_64) (revision id: df58cf2)

Original data directory /home/DATABASE/Default_DB is not empty!

하지만 말이 쉬워서 그렇지 해당 폴더를 비우게 되면 DB 운영을 중단해야 하는 경우가 발생한다.

운영해야 되는 상황에서는 힘든 경우가 발생한다.

그래서 여러 옵션을 찾아보고 시도를 했으나 번번히 실패했다.

내가 강구한 방법은 cnf 파일을 수정하는 것이다.

하지만, cnf 파일을 수정하기에는 위험하기에 /etc/my.cnf 를 백업한 후 백업한 파일을 수정하고 해당 수정 파일을 바라보도록 설정하였다.

(역시, 안될때에는 잠시 쉬면서 다른 방안 찾는것이.....ㅎ)

[root@DBTEST02:/home/backup/game/2016-09-20_11-40-34]# cp /etc/my.cnf /etc/my_backup.cnf

my_backup.cnf 내 BASEDIR 변수에 자신이 복구하고자 하는 위치의 정보를 설정

기존 /home/DATABASE/Default_DB를 /home/DATABASE/InnoDB/Game3로 변경

datadir = /home/DATABASE/InnoDB/Game3

[root@DBTEST02:/home/backup/game/2016-09-20_11-40-34]# innobackupex --defaults-file=/etc/my_backup.cnf --copy-back /home/backup/game/2016-09-20_11-40-34

160920 16:37:17 innobackupex: Starting the copy-back operation

IMPORTANT: Please check that the copy-back run completes successfully.

At the end of a successful copy-back run innobackupex

prints "completed OK!".

innobackupex version 2.4.4 based on MySQL server 5.7.13 Linux (x86_64) (revision id: df58cf2)

160920 16:37:17 [01] Copying ibdata1 to /home/DATABASE/InnoDB/Game3/ibdata1

160920 16:37:19 [01] ...done

160920 16:37:19 [01] Copying ./performance_schema/events_waits_summary_by_host_by_event_name.frm to /home/DATABASE/InnoDB/Game3/performance_schema/events_waits_summary_by_host_by_event_name.frm

160920 16:37:19 [01] ...done

160920 16:37:19 [01] Copying ./performance_schema/table_lock_waits_summary_by_table.frm to /home/DATABASE/InnoDB/Game3/performance_schema/table_lock_waits_summary_by_table.frm

160920 16:37:19 [01] ...done

....

160920 16:37:22 [01] Copying ./DARKEDEN/WeekItemGive.frm to /home/DATABASE/InnoDB/Game3/DARKEDEN/WeekItemGive.frm

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/SkullObject.frm to /home/DATABASE/InnoDB/Game3/DARKEDEN/SkullObject.frm

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/UserIPInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/UserIPInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/SetItemOptionInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/SetItemOptionInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/EffectHoodlumStigma.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/EffectHoodlumStigma.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/FasciaInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/FasciaInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/ETCInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/ETCInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/VampireETCInfo.frm to /home/DATABASE/InnoDB/Game3/DARKEDEN/VampireETCInfo.frm

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/TunningOptionRatioInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/TunningOptionRatioInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 completed OK!

이렇게 하면, 정상적으로 복구된 파일들을 확인할 수 있다.

하지만, 여기서 추가로 /etc/my.cnf 에 포트를 추가로 설정 및 복구된 파일들의 권한을 mysql로 변경해 준다.

이후, "mysqld_multi start 포트" 로 실행 후 자신이 복구하고자 하는 데이터를 복구 진행하면 된다.

정리

1. cnf 파일 백업 및 백업파일 BASEDIR 수정(복구를 원하는 폴더로 설정)

2. innobackupex --defaults-file=/etc/my_backup.cnf(BASEDIR 수정한파일) --copy-back /home/backup/game/2016-09-20_11-40-34(백업한 폴더)

3. 복구가 완료된 폴더에 권한을 mysql 로 수정

4. 복구를 위해 복구 파일을 DB로 올리기 위해 my.cnf 에 multi start 로 추가 (포트 추가- Clone DB)

5. mysqld_multi start 포트

6. 복구 확인

이렇게 mysql clone DB??? 를 진행해 보았다.

저작자표시 비영리

'MySQL > Xtrabackup' 카테고리의 다른 글

[Xtrabackup] Backup 방법2 (추가 full backup) (0)	2016.09.20
[Xtrabackup] Backup 방법 ( Full / Incremental) (2)	2016.09.13
[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32 (0)	2016.09.08

[Xtrabackup] Backup 방법2 (추가 full backup)

2016. 9. 20. 11:28

지난 innobackupex 명령어를 단순히 따라 하는 것에서 벗어나

하나씩 저희 회사에 맞게 변경을 하고 있습니다.

이게 진정 회사를 위한 공부겠죠..?

각설하고...

지난 명령어는 아래와 같습니다.

[root@DBTEST02:/root]# innobackupex --user=DB유저명 --password=비밀번호--socket=/tmp/mysql_8003.sock /home/backup/game/

나름 저희 회사에 맞게 변경한다고 한 것이지만 여기서 빼놓고 간 부분이 있습니다.

위와 같이 진해을 하면 Default DB 의 위치를 backup 한 다는 것을..

잠시 /etc/my.cnf 를 확인해 보면

[mysqld]

user = mysql

basedir = /usr/local/mysql

datadir = /home/DATABASE/Default_DB

tmpdir = /usr/local/mysql/DB/tmp

datadir 가 Default DB 위치다.

그래서 위의 innobackupex 를 하면 port 가 8003 인 곳의 datadir 가 아닌 Default 위치의 데이터가 백업 되는 것을 확인할 수 있다.

그렇다면, 어떻게 진행해야 될까?

아래와 같이 defaults-file 를 선언해 주면 된다.

[root@DBTEST02:/root]#innobackupex --defaults-file=/home/DATABASE/InnoDB/Game2/ --user=root --password= --socket=/tmp/mysql_8003.sock /home/backup/game/

여기서 --defaults-file 은 앞쪽에 위치해야 한다. 혹시나 해당 변수를 뒤에다 선언하면 에러가 발생한다.

xtrabackup: Error: --defaults-file must be specified first on the command line

제대로 백업이 되는지는 로그만 봐도 알 수 있다.

아래 보면 해당 위치의 DB까지 모두 백업 되는 것을 확인할 수 있다.

[root@DBTEST02:/home/backup/game]# innobackupex --defaults-file=/home/DATABASE/InnoDB/Game2/ --user=root --password= --socket=/tmp/mysql_8003.sock --databases=DARKEDEN /home/backup/game/

160920 10:52:00 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!".

160920 10:52:00 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/tmp/mysql_8003.sock' as 'root' (using password: NO).

160920 10:52:00 version_check Connected to MySQL server

160920 10:52:00 version_check Executing a version check against the server...

160920 10:52:00 version_check Done.

160920 10:52:00 Connecting to MySQL server host: localhost, user: root, password: set, port: 0, socket: /tmp/mysql_8003.sock

Using server version 5.6.32-debug-log

innobackupex version 2.4.4 based on MySQL server 5.7.13 Linux (x86_64) (revision id: df58cf2)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /home/DATABASE/InnoDB/Game2/

xtrabackup: open files limit requested 0, set to 1024

xtrabackup: using the following InnoDB configuration:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup: innodb_log_group_home_dir = ./

xtrabackup: innodb_log_files_in_group = 2

xtrabackup: innodb_log_file_size = 50331648

InnoDB: Number of pools: 1

160920 10:52:00 >> log scanned up to (21174002)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 442 for DARKEDEN/ShoulderArmorInfo, old maximum was 0

160920 10:52:01 >> log scanned up to (21174002)

160920 10:52:02 >> log scanned up to (21174002)

160920 10:52:03 >> log scanned up to (21174002)

160920 10:52:04 [01] Copying ./ibdata1 to /home/backup/game/2016-09-20_10-52-00/ibdata1

160920 10:52:04 >> log scanned up to (21174002)

160920 10:52:05 >> log scanned up to (21174002)

160920 10:52:05 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/ContributeDegree.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/ContributeDegree.ibd

160920 10:52:06 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/OustersWristletObject.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/OustersWristletObject.ibd

160920 10:52:06 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/SubInventoryInfo.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/SubInventoryInfo.ibd

160920 10:52:06 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/HighEnchantLog.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/HighEnchantLog.ibd

...

160920 10:52:10 [01] Copying ./DARKEDEN/VampireETCInfo.frm to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/VampireETCInfo.frm

160920 10:52:10 [01] ...done

160920 10:52:10 Finished backing up non-InnoDB tables and files

160920 10:52:10 [00] Writing xtrabackup_binlog_info

160920 10:52:10 [00] ...done

160920 10:52:10 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...

xtrabackup: The latest check point (for incremental): '21174002'

xtrabackup: Stopping log copying thread.

.160920 10:52:10 >> log scanned up to (21174002)

160920 10:52:10 Executing UNLOCK TABLES

160920 10:52:10 All tables unlocked

160920 10:52:10 Backup created in directory '/home/backup/game/2016-09-20_10-52-00'

MySQL binlog position: filename 'Bin_Log.000051', position '120'

160920 10:52:10 [00] Writing backup-my.cnf

160920 10:52:10 [00] ...done

160920 10:52:10 [00] Writing xtrabackup_info

160920 10:52:10 [00] ...done

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

160920 10:52:11 completed OK!

incremental 백업도 비슷하게 진행하면 될 것 같다.

저작자표시 비영리

'MySQL > Xtrabackup' 카테고리의 다른 글

[Xtrabackup] innobackupex Full backup 복구 (MySQL Clone DB???) (2)	2016.09.20
[Xtrabackup] Backup 방법 ( Full / Incremental) (2)	2016.09.13
[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32 (0)	2016.09.08

[Xtrabackup] Backup 방법 ( Full / Incremental)

2016. 9. 13. 11:59

Xtrabackup 을 사용하는 방법에 대해 테스트 해 보았다.

마음도 심숭생숭하여 빨리 진행될 일을 너무 느긋하게 진행 되었다.

InnoDB 를 이용한 백업 으로써 Incremental backup 도 함께 해 보았다.

Incremental 에 대한 개념은 Oracle Rman 백업과 같은 개념으로 생각해도 될 것 같다.

Full Backup 의 경우 데이터의 양이 증가할 수록 시간도 오래 걸린다.

이에 따라, 변경된 데이터만 백업을 함으로서 백업의 시간을 획기적으로 단축할 수 있다.

이후 복구 시에는 Full backup 으로 복구 후 나머지 변경된 데이터만 Incremental 백업을 가지고 적용함으로써

무손실로 복구를 할 수 있다.

물론 이 개념들은 모두 Oracle Rman 백업 / 복구 때의 지식으로 Xtrabackup 의 경우 다를 수도 있다.

추가적으로 MySQL LSN 이 있는데

* lsn 이 log sequence number 의 약자로써 전체 DB의 버전 정보를 뜻함

- 변경 사항이 발생할 때마다 번호가 증가하여 채번

* Oracle로 따져보면 SCN 와 비슷

(DB Link를 많이 사용하다 보면 SCN 관련하여 full 이 차서 DB down 되는 현상이 있엇던 것이 기억난다...11g 등에서 어느정도 해결되었다고는 했는데..)

1. Full Backup

* innobackupex 명령어를 이용하여 user 와 passwd 를 입력하여 진행

* Port를 따로 지정한 경우나, 멀티로 띄우는 경우 --socket 옵션을 지정하여 명시

* /home/backup/game/ 으로 어느 곳에 백업을 할 것인지 명시를 하게 되면, 자동으로 '2016-09-09_16-58-17' 처럼 날짜 시간으로 디렉토리 자동생성

* config 파일을 지정시 --defaults-file=MY.CNF 처럼 명시 가능

[root@DBTEST02:/root]# innobackupex --user=DB유저명 --password=비밀번호--socket=/tmp/mysql_8003.sock /home/backup/game/

....

160909 16:58:19 Executing UNLOCK TABLES

160909 16:58:19 All tables unlocked

160909 16:58:19 Backup created in directory '/home/backup/game/2016-09-09_16-58-17'

MySQL binlog position: filename 'Bin_Log.000049', position '7396794'

160909 16:58:19 [00] Writing backup-my.cnf

160909 16:58:19 [00] ...done

160909 16:58:19 [00] Writing xtrabackup_info

160909 16:58:19 [00] ...done

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

160909 16:58:19 completed OK!

2. Preparing a full backup with innobackupex

* 백업을 생성한 후에 해당 백업 데이터는 아직 restore 할 수 있는 상태가 아님.

* rollback 하는 commit되지 않은 transaction이나 재실행 되어야 하는 transaction이 있을 수 있음

* 미완된 작업들을 정리하는 작업을 함으로서 데이터 파일의 일관성을 유지하는 작업을 Prepare작업

* 해당 작업이 정상적으로 완료 되면 백업된 데이터 파일들은 이제 복구용으로 사용 가능

* innobackupex를 사용하여 백업 파일의 일관성을 맞추기 위해 --apply-log 옵션을 사용하면 된다. 백업된 위치를 옵션으로 주어 작업을 진행한다.

* Prepare 작업 동안에 백업이 진행되는 동안에 생성된 Transaction 내용을 담은 로그 파일안에 커밋된 Transaction 들을 재실행을 한다. 그리고, 그것들 중에 커밋 구문이 실행되지 않은 transaction들은 롤백된다.

이 작업을 완료하게 되면, 모든 정보들은 테이블 스페이스에 저장되고, 새로운 로그 파일이 생성된다.

내부적으로는 xtrabackup --prepare 를 2번 실행하게 된다.

Prepare 작업 시에 좀 더 빨리 진행하고 싶다면 --use-memoryh 옵션을 사용할 수 있다.(Default 100mb)

* innobackupex --apply-log --use-memory=4G /home/backup/game/2016-09-09_16-58-17

※ Transaction 의 일관성을 유지하기 위해서 innobackupex 의 Full backup을 진행한 후 완료된 작업에 대해(생성된 백업 디렉토리) --apply-log 옵션을 추가하여 한번 더 진행하면 파일의 일관성을 맞출 수 있다.

* 아래는 apply-log 를 진행 한 후의 메시지 들이다.

3. Incremental backup

- Incremental backup에 대한 개념은 초반에 살짝 언급한 바와 같이 백업 이후의 변경된 내용들에 대해서만 백업을 진행

- 기준은 LSN 의 정보를 보고 추적하여 진행

* --incremental-basedier 의 경우 마지막으로 full backup 한 위치에 대한 데이터 내용을 뜻하는 것으로, 해당 내용들을 확인 후 incremental backup을 진행하기 위한 기본 정보이다.

* 풀백업이든 증분 백업이든 최종 위치를 작성 후에 진행해야지만, 증분백업을 제대로 진행할 수 있다.

* innobackupex --incremental --user=DB유저ID --password=DB유저 패스워드 --socket=/tmp/mysql_8003.sock /home/backup/game/ --incremental-basedir=/home/backup/game/2016-09-12_10-59-37/

* incremental 백업을 완료 하게 되면 xtrabackup_checkpoints 파일이 생기는데 해당 내용을 확인해 보면 아래와 같다

backup_type = incremental

from_lsn = 1601102

to_lsn = 1601102

last_lsn = 1601102

compact = 0

recover_binlog_info = 0

* 혹시라도 lsn 을 알고 있다면, 해당 번호가지고 수동으로 incremental 를 진행할 수 있다.

(시작되는 번호를 명시하면 자동으로 마지막까지 진행 한다.)

innobackupex --incremental --user=DB유저ID --password=DB유저 패스워드 --socket=/tmp/mysql_8003.sock /home/backup/game/ --incremental-lsn=1600627

[root@DBTEST02:/home/backup/game/2016-09-12_11-26-40]# ll

total 108

-rw-r----- 1 root root 418 Sep 12 11:26 backup-my.cnf

-rw-r----- 1 root root 81920 Sep 12 11:26 ibdata1.delta

-rw-r----- 1 root root 44 Sep 12 11:26 ibdata1.meta

-rw-r----- 1 root root 23 Sep 12 11:26 xtrabackup_binlog_info

-rw-r----- 1 root root 117 Sep 12 11:26 xtrabackup_checkpoints

-rw-r----- 1 root root 563 Sep 12 11:26 xtrabackup_info

-rw-r----- 1 root root 2560 Sep 12 11:26 xtrabackup_logfile

[root@DBTEST02:/home/backup/game/2016-09-12_11-26-40]# vi xtrabackup_checkpoints

backup_type = incremental

from_lsn = 1600627

to_lsn = 1601102

last_lsn = 1601102

compact = 0

recover_binlog_info = 0

* backup_type = incremental 이라고 적혀 있으며 lsn 관련된 내용을 보면 위치를 확인할 수 있다.

* 반드시 백업이 완료 된 후

* incremetal 실행 결과 xtrabackup_checkpoints 파일을 확인해 보는 습관이 필요할 듯 싶다.

해당 문서는 아래 블로그를 참고로 하였습니다.

http://ani2life.com/wp/?p=1290

http://mysqldba.tistory.com/240

저작자표시 비영리

'MySQL > Xtrabackup' 카테고리의 다른 글

[Xtrabackup] innobackupex Full backup 복구 (MySQL Clone DB???) (2)	2016.09.20
[Xtrabackup] Backup 방법2 (추가 full backup) (0)	2016.09.20
[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32 (0)	2016.09.08

[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32

2016. 9. 8. 10:41

현재까지 우리회사 DB는 순전히 python으로 coldbackup 으로 일일 백업 및 주간 백업은 Coldbackup & MySQLDump 를 이용한 schema 백업을 해왔다.

이것이 가능한 이유는 매주 한번씩 정기점검을 진행하고, Slave 로 일일 백업 및 복구하여 조회용으로 했기에 가능했다.

하지만 5.6.32로 버전 업 및 InnoDB로 업그레이드 예정이라 이제는 다른 식으로 백업을 진행하는 것이 좋지 않을까 고민해 보다,

XtraBackup 에 대해 알게되어 테스트해 본다.

해당 Percona XtraBackup 의 경우 무료다.

아래는 Percona에서 제공하는 MySQL backup 툴과 자신들의 XtraBackup 의 차이점에 대해서 나열한 것이다. (내가 무료란것만 살짝 강조를...ㅋㅋ)

무료 및 Open Source 이며, MySQL 및 MariaDB 까지 지원되는 것이 강점이며, Linux 만 가능한게 단점이 아닐까 싶다.ㅠ

https://www.percona.com/doc/percona-xtrabackup/2.4/intro.html

MySQL Backup Tool Feature Comparison

Features	Percona XtraBackup	MySQL Enterprise backup
License	GPL	Proprietary
Price	Free	Included in subscription at $5000 per Server
Streaming and encryption formats	Open source	Proprietary
Supported MySQL flavors	MySQL, Percona Server, MariaDB,Percona XtraDB Cluster, MariaDB Galera Cluster	MySQL
Supported operating systems	Linux	Linux, Solaris, Windows, OSX, FreeBSD.
Non-blocking InnoDB backups [1]	Yes	Yes
Blocking MyISAM backups	Yes	Yes
Incremental backups	Yes	Yes
Full compressed backups	Yes	Yes
Incremental compressed backups	Yes
Fast incremental backups [2]	Yes
Incremental backups with archived logs feature in Percona Server	Yes
Incremental backups with REDO log only		Yes
Backup locks [8]	Yes
Encrypted backups	Yes	Yes [3]
Streaming backups	Yes	Yes
Parallel local backups	Yes	Yes
Parallel compression	Yes	Yes
Parallel encryption	Yes	Yes
Parallel apply-log	Yes
Parallel copy-back		Yes
Partial backups	Yes	Yes
Partial backups of individual partitions	Yes
Throttling [4]	Yes	Yes
Backup image validation		Yes
Point-in-time recovery support	Yes	Yes
Safe slave backups	Yes
Compact backups [5]	Yes
Buffer pool state backups	Yes
Individual tables export	Yes	Yes [6]
Individual partitions export	Yes
Restoring tables to a different server [7]	Yes	Yes
Data & index file statistics	Yes
InnoDB secondary indexes defragmentation	Yes
`rsync` support to minimize lock time	Yes
Improved `FTWRL` handling	Yes
Backup history table	Yes	Yes
Backup progress table		Yes
Offline backups		Yes
Backup to tape media managers		Yes
Cloud backups support		Amazon S3
External graphical user interfaces to backup/recovery	Zmanda Recovery Manager for MySQL	MySQL Workbench, MySQL Enterprise Monitor

사실 설치를 진행하면서 yum으로 설치는 하지 말자라고 생각 했지만...

결국은 패키지 의존성 체크 및 key 관련되서 애를 먹어 그냥 yum 으로 설치 하였다.

설치 방법은 아래 참고하면 된다.

https://www.percona.com/doc/percona-xtrabackup/2.2/installation/yum_repo.html

나는 아래에서 rpm 다운을 받은 뒤 진행했다.

https://www.percona.com/downloads/XtraBackup/

Yum으로 설치

$ yum localinstall percona-xtrabackup-24*

* key 관련하여 에러메시지는

1. vi /etc/yum.repos.d/percona-release.repo

2. 맨 하단에 아래 추가

############################################

# XTRABACKUP #

############################################

[percona]

name = CentOS $releasever - Percona

baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/

enabled = 1

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Percona

gpgcheck = 1

3. 해당 파일 확인 /etc/pki/rpm-gpg/RPM-GPG-KEY-Percona

없으면, 생성후 아래 내용 추가 (참조 : https://www.percona.com/downloads/percona-release/RPM-GPG-KEY-percona )

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.4.9 (GNU/Linux)

mQGiBEsm3aERBACyB1E9ixebIMRGtmD45c6c/wi2IVIa6O3G1f6cyHH4ump6ejOi

AX63hhEs4MUCGO7KnON1hpjuNN7MQZtGTJC0iX97X2Mk+IwB1KmBYN9sS/OqhA5C

itj2RAkug4PFHR9dy21v0flj66KjBS3GpuOadpcrZ/k0g7Zi6t7kDWV0hwCgxCa2

f/ESC2MN3q3j9hfMTBhhDCsD/3+iOxtDAUlPMIH50MdK5yqagdj8V/sxaHJ5u/zw

YQunRlhB9f9QUFfhfnjRn8wjeYasMARDctCde5nbx3Pc+nRIXoB4D1Z1ZxRzR/lb

7S4i8KRr9xhommFnDv/egkx+7X1aFp1f2wN2DQ4ecGF4EAAVHwFz8H4eQgsbLsa6

7DV3BACj1cBwCf8tckWsvFtQfCP4CiBB50Ku49MU2Nfwq7durfIiePF4IIYRDZgg

kHKSfP3oUZBGJx00BujtTobERraaV7lIRIwETZao76MqGt9K1uIqw4NT/jAbi9ce

rFaOmAkaujbcB11HYIyjtkAGq9mXxaVqCC3RPWGr+fqAx/akBLQ2UGVyY29uYSBN

eVNRTCBEZXZlbG9wbWVudCBUZWFtIDxteXNxbC1kZXZAcGVyY29uYS5jb20+iGAE

ExECACAFAksm3aECGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAcTL3NzS79

Kpk/AKCQKSEgwX9r8jR+6tAnCVpzyUFOQwCfX+fw3OAoYeFZB3eu2oT8OBTiVYu5

Ag0ESybdoRAIAKKUV8rbqlB8qwZdWlmrwQqg3o7OpoAJ53/QOIySDmqy5TmNEPLm

lHkwGqEqfbFYoTbOCEEJi2yFLg9UJCSBM/sfPaqb2jGP7fc0nZBgUBnFuA9USX72

O0PzVAF7rCnWaIz76iY+AMI6xKeRy91TxYo/yenF1nRSJ+rExwlPcHgI685GNuFG

chAExMTgbnoPx1ka1Vqbe6iza+FnJq3f4p9luGbZdSParGdlKhGqvVUJ3FLeLTqt

caOn5cN2ZsdakE07GzdSktVtdYPT5BNMKgOAxhXKy11IPLj2Z5C33iVYSXjpTelJ

b2qHvcg9XDMhmYJyE3O4AWFh2no3Jf4ypIcABA0IAJO8ms9ov6bFqFTqA0UW2gWQ

cKFN4Q6NPV6IW0rV61ONLUc0VFXvYDtwsRbUmUYkB/L/R9fHj4lRUDbGEQrLCoE+

/HyYvr2rxP94PT6Bkjk/aiCCPAKZRj5CFUKRpShfDIiow9qxtqv7yVd514Qqmjb4

eEihtcjltGAoS54+6C3lbjrHUQhLwPGqlAh8uZKzfSZq0C06kTxiEqsG6VDDYWy6

L7qaMwOqWdQtdekKiCk8w/FoovsMYED2qlWEt0i52G+0CjoRFx2zNsN3v4dWiIhk

ZSL00Mx+g3NA7pQ1Yo5Vhok034mP8L2fBLhhWaK3LG63jYvd0HLkUFhNG+xjkpeI

SQQYEQIACQUCSybdoQIbDAAKCRAcTL3NzS79KlacAJ0aAkBQapIaHNvmAhtVjLPN

wke4ZgCePe3sPPF49lBal7QaYPdjqapa1SQ=

=qcCk

-----END PGP PUBLIC KEY BLOCK-----

참고 : http://openlife.tistory.com/362

* 이마저도 안된다면 과감하게 yum update 후 진행을 해 보는 것도 좋은 방법이다.

$ yum update

-- 꽤나 시간이 오래 걸려도 나름 이후에는 한방에 되는 경우도 있다.

$ yum list | grep percona

...
percona-xtrabackup-20.x86_64               2.0.8-587.rhel5             percona-release-x86_64
percona-xtrabackup-20-debuginfo.x86_64     2.0.8-587.rhel5             percona-release-x86_64
percona-xtrabackup-20-test.x86_64          2.0.8-587.rhel5             percona-release-x86_64
percona-xtrabackup-21.x86_64               2.1.9-746.rhel5             percona-release-x86_64
percona-xtrabackup-21-debuginfo.x86_64     2.1.9-746.rhel5             percona-release-x86_64
percona-xtrabackup-22.x86_64               2.2.13-1.el5                percona-release-x86_64
percona-xtrabackup-22-debuginfo.x86_64     2.2.13-1.el5                percona-release-x86_64
percona-xtrabackup-debuginfo.x86_64        2.3.2-1.el5                 percona-release-x86_64
percona-xtrabackup-test.x86_64             2.3.2-1.el5                 percona-release-x86_64
percona-xtrabackup-test-21.x86_64          2.1.9-746.rhel5             percona-release-x86_64
percona-xtrabackup-test-22.x86_64          2.2.13-1.el5                percona-release-x86_64
...

$ yum install percona-xtrabackup

참고 https://www.percona.com/doc/percona-xtrabackup/2.2/installation/yum_repo.html

저작자표시 비영리

'MySQL > Xtrabackup' 카테고리의 다른 글

[Xtrabackup] innobackupex Full backup 복구 (MySQL Clone DB???) (2)	2016.09.20
[Xtrabackup] Backup 방법2 (추가 full backup) (0)	2016.09.20
[Xtrabackup] Backup 방법 ( Full / Incremental) (2)	2016.09.13

PREV 1 NEXT

Louis.Kim 의 제 3막