반응형

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

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


대부분의 블로그나 심지어 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


[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??? 를 진행해 보았다.

반응형
  1. Test 2016.09.27 21:31

    익명으로 작성가능 테스트

  2. 크롬테스트 2016.09.27 21:35

    탭으로 옮길 시 안되지만, 글상자 클릭 시 이미지 생성

반응형

지난 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 백업도 비슷하게 진행하면 될 것 같다.


반응형
반응형

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


반응형
  1. 익명 2018.07.12 17:51

    비밀댓글입니다

    • 2018.12.27 12:08

      비밀댓글입니다

반응형

현재까지 우리회사 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

FeaturesPercona XtraBackupMySQL Enterprise backup
LicenseGPLProprietary
PriceFreeIncluded in subscription at $5000 per Server
Streaming and encryption formatsOpen sourceProprietary
Supported MySQL flavorsMySQL, Percona Server, MariaDB,Percona XtraDB Cluster, MariaDB Galera ClusterMySQL
Supported operating systemsLinuxLinux, Solaris, Windows, OSX, FreeBSD.
Non-blocking InnoDB backups [1]YesYes
Blocking MyISAM backupsYesYes
Incremental backupsYesYes
Full compressed backupsYesYes
Incremental compressed backupsYes 
Fast incremental backups [2]Yes 
Incremental backups with archived logs feature in Percona ServerYes 
Incremental backups with REDO log only Yes
Backup locks [8]Yes 
Encrypted backupsYesYes [3]
Streaming backupsYesYes
Parallel local backupsYesYes
Parallel compressionYesYes
Parallel encryptionYesYes
Parallel apply-logYes 
Parallel copy-back Yes
Partial backupsYesYes
Partial backups of individual partitionsYes 
Throttling [4]YesYes
Backup image validation Yes
Point-in-time recovery supportYesYes
Safe slave backupsYes 
Compact backups [5]Yes 
Buffer pool state backupsYes 
Individual tables exportYesYes [6]
Individual partitions exportYes 
Restoring tables to a different server [7]YesYes
Data & index file statisticsYes 
InnoDB secondary indexes defragmentationYes 
rsync support to minimize lock timeYes 
Improved FTWRL handlingYes 
Backup history tableYesYes
Backup progress table Yes
Offline backups Yes
Backup to tape media managers Yes
Cloud backups support Amazon S3
External graphical user interfaces to backup/recoveryZmanda Recovery Manager for MySQLMySQL 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-----



* 이마저도 안된다면 과감하게 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

반응형

+ Recent posts