Last Updated on 1월 8, 2024 by Jade(정현호)
안녕하세요
이번 포스팅에서는 MySQL에서 Xtrabackup을 이용한 온라인 백업 수행 과 복구 그리고 복제 설정에 대해서 5.7 버전과 8.0 버전 대상으로 내용을 살펴보겠습니다.
Contents
Percona XtraBackup
Percona XtraBackup은 MySQL 기반 서버를 위한 오픈 소스 핫 백업 유틸리티로, 계획된 백업 수행 기간 동안 데이터베이스를 완전히 사용할 수 있도록 유지합니다.
Percona XtraBackup 24x7 365일 언제나 고부하 서버도 트랜잭션 볼륨이 적은 운영 환경에서도 서버의 성능을 중단하지 않고 원활하게 백업할 수 있도록 설계되었습니다.
Percona XtraBackup(PXB)은 MySQL에 대한 포괄적이고 응답성이 뛰어나며 비용 효율적인 데이터베이스 지원을 원하는 조직에 제공되는 100% 오픈 소스 백업 솔루션입니다.
Percona XtraBackup을 MySQL에서 사용할 경우 사용하는 MySQL 버전에 따라 Percona XtraBackup 버전을 구분해서 사용해야 합니다.
- MySQL 5.7 버전 : Xtrabackup 2.4
- MySQL 8.0 버전 : Xtrabackup 8.0
- MySQL 8.1 버전 : Xtrabackup 8.1
XtraBackup 2.4
MySQL 5.7 버전에서는 Xtrabackup 2.4 버전을 사용하여 백업 및 복구를 사용합니다.
Xtrabackup 2.4 환경에서는 다음과 같은 버전 환경에서 진행하였습니다.
OS: CentOS 7.8
MySQL : 5.7.31
MySQL data 경로 : /usr/local/mysql/data
MySQL replication 유저 : repl_user
XtraBackup : 2.4.21
설치 및 구성
Repository 구성
- Master/Slave 모두 수행
먼저 xtrabackup 을 받기 위해서 repository 를 구성합니다
[root] yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
xtrabackup 와 qpress 설치
- Master/Slave 모두 수행
[root] yum install -y qpress percona-xtrabackup-24
[추가] Ubuntu 환경에서의 xtrabackup 설치 과정
먼저 아래의 절차로 apt repository 구성 및 설치 가능한 버전에 대해서 search를 진행합니다.
$ wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb $ sudo dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb $ sudo apt update $ sudo apt search xtrabackup
xtrabackup 버전을 2.4 를 설치할지 MySQL 8.0 버전에 대응하는 xtrabackup 8.0 버전을 설치할지를 선택하여 설치를 진행합니다.
$ sudo apt install percona-xtrabackup-24 or $ sudo apt install percona-xtrabackup-80
그 다음 qpress 를 설치합니다.
$ sudo apt install qpress
백업 유저 및 Replication 유저 생성
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'bkpuser';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS,
REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost';
mysql> CREATE USER 'repl_user'@'%' IDENTIFIED BY 'repl_user';
mysql> GRANT REPLICATION SLAVE,
REPLICATION CLIENT ON *.* to 'repl_user'@'%';
mysql> FLUSH PRIVILEGES;
유저 생성은 Master 서버에만 생성을 진행하면 됩니다.
백업 수행
백업 받을 디렉토리 생성 및 백업 수행
포스팅에서 사용된 디텍토리는 예시입니다.
[root]# mkdir -p /root/backup/ [root]# xtrabackup \ --defaults-file=/etc/my.cnf \ --host="localhost" \ --user="bkpuser" \ --password="bkpuser" \ --compress \ --compress_threads=4 \ --parallel=4 --no-lock \ --stream=xbstream /tmp > /root/backup/backup.xbstream [root]# ls -alrth /root/backup/backup.xbstream -rw-r--r--. 1 root root 1.5G Feb 2 18:27 /root/backup/backup.xbstream
Note
innobackupex 명령어(유틸리티) 둘 다 사용 가능하지만, 2.4 버전에서의 innobackupex 명령어는 xtrabackup 의 심볼릭 링크로 되어있습니다. 그래서 포스팅에서는 2.4 버전에서도 xtrabackup 명령어를 사용하였습니다.
파일을 슬레이브 서버로 전송
먼저 슬레이스 서버에서 디렉토리 생성합니다
* 포스팅에서 사용된 디텍토리는 예시입니다.
[root]# mkdir -p /root/backup/xbstream
백업 파일 전송 - 마스터 서버에서 수행
마스터 서버에서 슬레이브 서버로 백업파일을 전송합니다.
[root]# rsync -av --progress /root/backup/backup.xbstream \
root@슬레이브서버IP:/root/backup/xbstream/
root@ip's password:
sending incremental file list
backup.xbstream
133,758,976 8% 14.84MB/s 0:01:33
rsync 의 경우 전송받는 서버에도 같이 존재해야 하며 rsync 이외 scp 나 sftp 를 사용하여도 됩니다.
백업 리스토어
파일 묶음 해제
먼저 슬레이브 서버에서 전송받은 stream 형태의 파일을 해제를 진행합니다
[root]# cd /root/backup/xbstream [root]# xbstream -x < backup.xbstream -C /root/backup/ ls -al /root/backup/ total 178060 drwxr-xr-x. 11 root root 4096 Feb 3 10:56 . dr-xr-x---. 12 root root 4096 Feb 3 10:55 .. -rw-r-----. 1 root root 492 Feb 3 10:56 backup-my.cnf.qp drwxr-x---. 2 root root 4096 Feb 3 10:56 employees -rw-r-----. 1 root root 550 Feb 3 10:56 ib_buffer_pool.qp -rw-r-----. 1 root root 2923584 Feb 3 10:55 ibdata1.qp drwxr-x---. 2 root root 4096 Feb 3 10:56 mysql <..중략..>
압축 해제
파일을 보면 ibdata1.qp 와 같이 qp 확장자가 확인되며 이러한 파일은 qpress 로 압축된 상태입니다 압축을 해제하는 방법은 2가지 있습니다.
• 첫번째로 xtrabackup --decompress 를 사용하여 압축해제를 할 수 있으며 이 경우 압축이 해제된 파일과 압축된 qp 파일이 2개가 존재하게 됩니다.
필요시 아래 커맨드를 통해 qp 파일을 삭제할 수 있습니다.
[root]# find . -type f -name "*.qp" -exec rm -v {} \;
• 두번째로 아래의 qpress 유틸리티를 사용하여 아래 명령어 조합으로 압축을 해제할 수 있습니다 아래 명령어의 경우 압축 해제 후 qp 파일을 삭제하게 됩니다.
[root]# cd /root/backup/ [root]# for bf in `find . -iname "*\.qp"`; do qpress -d $bf $(dirname $bf) && /usr/bin/rm $bf; done
포스팅 에서는 xtrabackup --decompress 을 통해 진행하였습니다
[root]# xtrabackup --decompress /root/backup/ [root]# ls -al /root/backup/ total 616372 drwxr-xr-x. 11 root root 4096 Feb 3 11:50 . dr-xr-x---. 12 root root 4096 Feb 3 11:08 .. -rw-r--r--. 1 root root 517 Feb 3 11:50 backup-my.cnf -rw-r-----. 1 root root 492 Feb 3 11:09 backup-my.cnf.qp drwxr-x---. 2 root root 4096 Feb 3 11:50 employees -rw-r--r--. 1 root root 823 Feb 3 11:50 ib_buffer_pool -rw-r-----. 1 root root 550 Feb 3 11:09 ib_buffer_pool.qp <..중략..>
apply log
apply log 단계를 수행합니다.
[root]# xtrabackup --apply-log /root/backup/
data dir 삭제
삭제 전 Slave DB 가 기동 중이라면 먼저 중지가 필요하며 기존 data dir 를 삭제하거나 mv 합니다.
포스팅에서 data 디렉토리는 /usr/local/mysql/data 을 사용하고 있습니다.
[root]# systemctl stop mysqld [root]# cd /usr/local/mysql [root]# rm -rf data [root]# mkdir data [root]# chown -R mysql:mysql data
데이터 파일 위치 원복
백업 파일에 대해서 원복은 --copy-back 이니 --move-back 을 사용하면 되며 copy는 백업에서 data 디렉토리로 복제를 하게 되고, move 는 data 디렉토리로 백업 파일을 옮기게 됩니다.
공간적으로 파일을 2개 유지하기 하기 어렵거나 하면 --move-back 을 사용하면 되며, 백업과 복구를 다시 해야 할 필요성이 있다면 재사용을 위해 --copy-back 을 사용하시면 됩니다.
파일이 모두 복사(원복) 되었다면 디렉토리와 파일에 대해서 소유권을 변경합니다.
[root]# xtrabackup --defaults-file=/etc/my.cnf \ --copy-back /root/backup/ [root]# chown -R mysql:mysql /usr/local/mysql/data
[참고] data 디렉토리 및 log 디렉토리 아래에 다른 디렉토리나 파일이 있어서는 안 됩니다. 디렉토리는 비워져 있어야 합니다.
Slave DB 를 시작합니다.
[root]# systemctl start mysqld
Replication 설정
마스터 정보 조회
백업 파일 중에 xtrabackup_info 이나 xtrabackup_binlog_info 에서 binlog 파일명과 log position 정보를 알수 있습니다.
[root]# cd /root/backup
[root]# cat xtrabackup_info
<..중략..>
tool_name = innobackupex
tool_command = --host=localhost --user=bkpuser
--compress_threads=4 --parallel=4
--password=... --compress
--no-lock --stream=xbstream /tmp
tool_version = 2.4.21
ibbackup_version = 2.4.21
server_version = 5.7.31-log
<..중략..>
binlog_pos = filename 'binlog.000080', position '815'
<..중략..>
[참고] Slave(Replica) 에서 백업 받은 파일로 추가적인 Replication 을 구성하려고 할 경우에는 xtrabackup_slave_info 파일을 참조하면 백업 받은 Slave DB가 참조하는(바라보는) Master 서버의 정보를 확인할 수 있으며 이럴 경우 백업 시 "--slave-info" 옵션을 사용해야 정보가 남게 됩니다.
Slave 에서 다시 Replication 을 설정하는 Relay Replication 을 설정하려면 slave 에서 binlog 활성화 후에 xtrabackup 을 수행한 다음 다른 서버에서 Replication 설정 시 xtrabackup_info 을 참조하시면 백업 받은 slave의 정보를 확인할 수 있습니다.
replication 설정 및 확인
MySQL 에 접속하여 change master 구문을 통해 복제 설정을 진행하면 되며, 복제 설정 후 show slave status\G 명령어를 통해 상태 및 정상 복제 여부를 확인하면 됩니다
[참고] --login-path 에 대한 정보는 아래 포스팅을 참조하시면 됩니다.
user$ mysql --login-path=dba mysql> change master to master_host='마스터서버IP',master_port=포트번호, master_user='repl_user', master_password='repl_user', master_log_file='binlog.000001',master_log_pos=154; mysql> start slave; mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 마스터서버IP Master_User: repl_user Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000080 Read_Master_Log_Pos: 815 Relay_Log_File: relay_log.000002 Relay_Log_Pos: 317 Relay_Master_Log_File: binlog.000080 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 815 Relay_Log_Space: 518 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_UUID: 12416d15-0bfa-11eb-ad17-080027d4f8ed Master_Info_File: /usr/local/mysql/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version:
여기까지 해서 MySQL 5.7버전에서 Xtrabackup 2.4 버전을 사용한 MySQL 백업, 복구 및 Replication 구성에 대해서 확인하였습니다.
XtraBackup 8.0
MySQL 8.0 버전에서는 Xtrabackup 8.0 버전을 사용해서 MySQL의 백업 및 복구를 진행합니다.
진행하는 전반적인 시나리오나 방법은 Xtrabackup2.4 부분과 유사하며, 명령어 옵션 등이 일부가 차이가 있는 부분 위주로 설명 드리겠습니다.
Xtrabackup 8.0은 다음과 같은 환경에서 진행하였습니다.
OS: CentOS 7.9
MySQL: 8.0.23
MySQL replication 유저: repl_user
XtraBackup: 8.0.25-17
설치
설치는 repository 를 설정하여 진행하도록 하겠습니다.
설치는 Source 와 Replication 될 서버 모두에 설치를 진행하면 됩니다.
-- Linux 7.x 버전 yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm -- Linux 8.0 의 경우 dnf 를 사용 dnf install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
Repository 가 구성되었다면 설치를 진행하면 됩니다 설치시 qpress 도 같이 설치를 하도록 하겠습니다.
-- Linux 7.x yum install -y qpress percona-xtrabackup-80 -- Linux 8.x 에서는 dnf 사용 dnf install -y qpress percona-xtrabackup-80
[압축 방식의 변경 관련]
• Percona XtraBackup 8.0.31-24 이전 버전까지는 qpress/QuickLZ 압축을 사용하였습니다. 그렇기 때문에 qpress를 같이 설치를 하였습니다.
• Percona XtraBackup 8.0.31-24 버전 부터는 qpress/QuickLZ 방식에 대해서 deprecated 되었으며 향후 버전에서는 삭제될 예정이며 LZ4 or Zstandard (ZSTD) 압축방식의 사용이 권장되고 있습니다.
• Percona XtraBackup 8.0.34-29 버전에서부터 qpress/QuickLZ 제거되었으며 ZSTD 압축 방식이 GA 되었고 ZSTD 가 compress 옵션 사용시 기본 압축 방식이 되었습니다.
이에 따라서 사용하는 Xtrabackup 버전에 따라서 앞으로는 qpress를 설치할 필요가 없으며 dnf(yum)과 같이 패키지 시스템으로 설치시 xtrabackup 버전에 따라서 zstd 패키지도 종속 패키지로 같이 설치가 되게 됩니다.
[참고] 별도로 컴파일을 통해 설치를 진행하려고 할 경우 아래 포스팅을 참조하시면 됩니다.
해당 포스팅은 ARM 아키텍처 용으로는 컴파일 빌드 된 배포버전이 존재하지 않아 컴파일 빌드로 진행한 내용입니다.
유저 생성
백업을 수행할 별도의 유저를 생성하도록 하겠습니다. 이전의 2.4 버전과 다르게 몇 가지 필요 권한이 추가되었습니다.
CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cr%T'; GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT,BACKUP_ADMIN ON *.* TO 'bkpuser'@'localhost'; GRANT SELECT ON performance_schema.* TO 'bkpuser'@'localhost'; FLUSH PRIVILEGES;
* 계정명 과 패스워드는 예시입니다.
Replication 에서 사용할 유저를 생성하도록 하겠습니다
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'repl_user'; GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* to 'repl_user'@'%';
* 계정명과 패스워드는 예시입니다.
백업 수행 및 전송
xbstream 을 통해서 압축 및 묶음을 같이 진행하는 형태로 백업을 수행하도록 하겠습니다.
백업 받을 디렉토리 생성
-- 백업파일을 위한 디렉토리 생성 ~]# mkdir -p /root/backup
디렉토리 경로 및 디렉토리 이름을 포스팅에서의 예시입니다.
xtrabackup 명령어를 수행합니다.
~]# xtrabackup --defaults-file=/etc/my.cnf \ --user="bkpuser" \ --password="s3cr%T" \ --backup \ --no-lock --parallel=4 \ --compress \ --compress-threads=4 \ --stream=xbstream --target_dir=/tmp/ > /root/backup/backup_80.xbstream
백업이 완료되었다면 Replica 로 구성할 서버로 백업 파일을 전송을 합니다.
~]# rsync -avr --progress /root/backup/backup_80.xbstream \ 계정명@다른서버IP:~/
rsync 대신 scp 나 sftp 로 파일을 전송해도 됩니다.
파일 압축 해제
전송받은 파일의 묶음 해제를 진행하기 위해서 디렉토리를 생성 후에 묶음 해제를 진행하도록 하겠습니다.
-- 백업파일을 위한 디렉토리 생성 ~]# mkdir -p /root/xbstream ~]# mkdir -p /root/backup -- 전송받은 백업 파일 이동 ~]# mv backup_80.xbstream /root/xbstream
~]# cd /root/xbstream -- 묶음 해제 - 대상경로 : /root/backup/ ~]# xbstream -x < backup_80.xbstream -C /root/backup/
xbstream 으로 묶여 있던 파일이 해제되었으며 backup 수행시에 --compress 옵션을 사용하였기 때문에 각 파일 개별 마다 아래와 같이 qpress 로 압축이 되어있습니다.
파일을 보면 ib_system.qp 와 같이 qp 확장자가 확인되며 qpress 로 압축된 상태입니다.
~]# cd /root/backup/ ~]# ls -al <..중략..> -rw-r-----. 1 root root 5401 Jul 29 20:54 ib_buffer_pool.qp -rw-r-----. 1 root root 1404836 Jul 29 20:54 ib_system.qp drwxr-x---. 2 root root 31 Jul 29 20:54 sys -rw-r-----. 1 root root 1047570 Jul 29 20:54 undo_001.qp -rw-r-----. 1 root root 985311 Jul 29 20:54 undo_002.qp -rw-r-----. 1 root root 192 Jul 29 20:54 xtrabackup_binlog_info.qp -rw-r-----. 1 root root 99 Jul 29 20:54 xtrabackup_checkpoints -rw-r-----. 1 root root 645 Jul 29 20:54 xtrabackup_info.qp -rw-r-----. 1 root root 55346 Jul 29 20:54 xtrabackup_logfile.qp -rw-r-----. 1 root root 130 Jul 29 20:54 xtrabackup_tablespaces.qp <..중략..>
최근 버전에서는 qpress 대신에 zstd가 사용되기 때문에 zstd로 압축된 경우 다음과 같이 확장자가 zst 가 되게 됩니다.
-rw-r----- 1 root root 308 1월 6 23:53 backup-my.cnf.zst -rw-r----- 1 root root 164 1월 6 23:53 binlog.000004.zst -rw-r----- 1 root root 49 1월 6 23:53 binlog.index.zst -rw-r----- 1 root root 8330 1월 6 23:53 ib_buffer_pool.zst -rw-r----- 1 root root 7219 1월 6 23:53 ib_system.zst drwxr-x--- 1 root root 167 1월 6 23:53 mysql -rw-r----- 1 root root 5782425 1월 6 23:53 mysql.ibd.zst drwxr-x--- 1 root root 4096 1월 6 23:53 mysql_innodb_cluster_metadata drwxr-x--- 1 root root 180 1월 6 23:53 performance_schema drwxr-x--- 1 root root 32 1월 6 23:53 sys -rw-r----- 1 root root 486796 1월 6 23:53 undo_001.zst -rw-r----- 1 root root 712232 1월 6 23:53 undo_002.zst -rw-r----- 1 root root 123 1월 6 23:53 xtrabackup_binlog_info.zst -rw-r----- 1 root root 129 1월 6 23:53 xtrabackup_checkpoints
압축을 해제하는 방법은 2가지 있습니다.
• 첫번째로 xtrabackup --decompress 를 사용하여 압축해제를 할 수 있으며 이 경우 압축이 해제된 파일과 압축된 qp 파일이 2개가 존재하게 됩니다.
필요시 아래 커맨드를 통해 qp 파일을 삭제할 수 있습니다.
~]# find . -type f -name "*.qp" -exec rm -v {} \;
또는 --remove-original 옵션 같이 사용하여 압축 파일을 삭제할 수 있습니다.
• 두번째로 qpress 방식으로 압축된 경우 qpress 유틸리티를 사용하여 다음의 명령어 조합으로 압축을 해제할 수 있습니다.
아래 명령어의 경우 압축 해제 후 qp 파일을 삭제하게 됩니다.
~]# cd /root/backup/ ~]# for bf in `find . -iname "*\.qp"`; do qpress -d $bf $(dirname $bf) && /usr/bin/rm $bf; done
zstd 방식으로 압축된 경우 --decompress 옵션을 사용해서 압축을 해제하면 됩니다.
포스팅에서는 xtrabackup --decompress 을 통해 진행하였습니다
~]# xtrabackup \ --decompress-threads=8 \ --decompress \ --target_dir=/root/backup/
2.4 버전에서의 xtrabackup --parallel --decompress 대신 --decompress-threads 옵션을 사용할 수 있습니다.
Prepare 및 copy-back
2.4 버전에서 apply log 가 8.0 버전에서는 prepare 옵션으로 변경되었습니다. 아래와 같이 prepare를 실행 합니다.
~]# xtrabackup --prepare --target-dir=/data/backup/
완료되었다면 데이터 파일 위치를 원복을 진행하면 되며, 파일을 원복하기 전에 이전의 디렉토리가 존재한다면 삭제 후 다시 생성 등의 작업이 필요 하며 MySQL 실행 중이라면 종료해야 합니다(디렉토리가 비어 있어야 함)
-- MySQL 이 시작되어 있다면 종료 ~]# systemctl stop mysqld -- 데이터 디렉토리 재생성 ~]# cd /var/lib ~]# mv mysql mysql.remove ~]# mkdir mysql
파일을 원복 하는 방식은 move-back 과 copy-back 이 있으며 포스팅에서는 copy-back 으로 진행하였습니다.
~]# xtrabackup --defaults-file=/etc/my.cnf \ --copy-back \ --target_dir=/root/backup
파일이 원복 된 후 디렉토리 및 파일의 소유권 및 퍼미션을 변경합니다.
~]# cd /var/lib/ ~]# chown -R mysql:mysql /var/lib/mysql ~]# chmod 700 /var/lib/mysql ~]# ls -alZ | grep mysql -- 아래 작업은 SELinux 활성화 일 경우 실행 ~]# /bin/chcon -R -u system_u \ -r object_r -t mysqld_db_t /var/lib/mysql
마지막의 chcon 은 SELinux 활성화 환경에서 실행하시면 됩니다. SELinux가 활성화되지 않은 환경에서는 해당 내용을 생략합니다.
DB 시작 및 복제 구성
DB 를 시작하기전에 XtraBackup 에 있는 purge gtid 값을 확인합니다.
~]$ cat /root/backup/xtrabackup_binlog_info binlog.000019 2446 2fedb69b-ce8c-11ea-a59a-0200170018a0:1-39689,41fb0e72-eeb5-11eb-a1d8-0200170018a0:1-421992 <----
또는 xtrabackup_info 파일 안의 내용을 확인하여도 동일한 내용을 확인할 수 있습니다.
이제 MySQL 를 시작합니다.
~]# systemctl start mysqld
시작이 완료되었다면 복제설정을 진행합니다.
-- Binlog POS 기반 Replication CHANGE MASTER TO MASTER_HOST='마스터IP', MASTER_PORT=3306, MASTER_USER='repl_user', MASTER_PASSWORD='repl_user', master_log_file='binlog.000019', master_log_pos=2446; start slave; show slave status\G -- GTID POS 기반 Replication RESET MASTER; SET GLOBAL gtid_purged='2fedb69b-ce8c-11ea-a59a-0200170018a0:1-39689,41fb0e72-eeb5-11eb-a1d8-0200170018a0:1-421992'; CHANGE MASTER TO MASTER_HOST='마스터IP', MASTER_PORT=3306, MASTER_USER='repl_user', MASTER_PASSWORD='repl_user', MASTER_AUTO_POSITION = 1; start slave; show slave status\G
Binlog POS 기반과 GTID 기반은 위의 내용과 같이 설정하여 사용할 수 있습니다.
[참조] 복제 사용 중 에러의 의해서 에러를 Skip 해야 할 경우 아래 포스팅을 참조하시면 됩니다.
8.0 버전에서는 innobackupex 명령어(심볼릭 링크)가 없어져서 xtrabackup 으로만 사용해야 한다는 점과 일부 옵션의 변화가 있으나 전반적으로는 2.4 버전과 유사하게 사용할 수 있습니다.
Reference
Reference link
percona.com/streaming_backups_innobackupex.html[Link]
percona.com/recipes_ibkx_compressed.html[Link]
percona.com/streaming_backups_innobackupex.html[Link]
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
