- 인쇄
- PDF
Backup
- 인쇄
- PDF
Classic 환경에서 이용 가능합니다 .
Backup에서는 Cloud DB for MySQL을 사용 중인 사용자의 캐시 데이터를 안전하게 보관하기 위해 서버별로 설정해놓은 백업 정보를 확인할 수 있습니다. 또한 장애가 발생하여 캐시 데이터가 손실된 경우 보관 중이던 백업 파일로 복원을 진행할 수도 있습니다. 고가용성 설정을 사용하는 서버 뿐만 아니라 Stand Alone Server도 백업 및 복원 기능을 사용할 수 있습니다. 단, Stand Alone Server는 시점 복원 기능은 지원되지 않습니다.
백업과 복원을 사용하기 위해서 우선 Cloud DB for MySQL에서 제공하고 있는 백업에 대한 기본 수행 규칙을 이해하는 것이 좋습니다. 백업 기본 수행 규칙은 다음과 같습니다.
- 백업 수행 방식
- 하루 한 번씩 매일 수행
- 자동 설정과 사용자 정의 설정 중 선택
- 자동 설정: MySQL Server 생성 시 임의의 시간이 지정되며, 이후 처음 백업된 시간과 유사한 시간에 백업 수행
- 사용자 정의 설정: 사용자가 선택한 시간 +15분 내 백업 수행 시작
- 예외 상황
- DB 생성 후 30분 이내에는 백업이 수행
- DB 설정이 변경될 경우 백업 시간 +5분 뒤 수행
- 백업 파일
- 보관 기간: 사용자 설정에 따라 최대 30일까지 보관 가능
- 저장 위치: 별도의 데이터 스토리지(백업 파일 크기에 따라 스토리지 계약 진행)
Backup 화면
Backup 이용을 위한 기본적인 설명은 다음과 같습니다.
영역 | 설명 |
---|---|
① 메뉴 이름 | 현재 확인 중인 메뉴 이름 |
② 기본 기능 | Cloud DB for MySQL 상세 정보 확인, Backup 화면 새로 고침 |
③ 백업 목록 | 설정해 놓은 서버별 백업 설정 및 설정 정보 |
백업 설정 목록 확인
운영 중인 MySQL Server별 백업 설정 목록을 확인할 수 있습니다. 백업 설정 목록을 확인하는 방법은 다음과 같습니다.
- 네이버 클라우드 플랫폼 콘솔의 Classic 환경에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
- Backup 메뉴를 클릭해 주십시오.
- 백업 설정 목록이 나타나면 필요한 정보를 확인해 주십시오.
- DB 서비스 이름: 사용자가 지정한 DB Service 이름
- Backup 보관일: 백업 파일을 데이터 스토리지에 저장하여 보관하는 최대 일수
- Backup 시작시간: 매일 1회 백업을 수행하는 시간
- Backup 데이터 크기: 완료된 백업 파일의 크기
- 마지막 Backup 일시: 최근에 수행 완료한 백업 날짜
- 상세정보 보기: 서버별 생성된 백업 파일 목록의 상세 정보 및 복원, Object Storage에 저장
서버별 백업 파일 목록 확인
백업 수행을 완료하여 서버별로 생성된 백업 파일 목록을 확인하는 방법은 다음과 같습니다.
- 네이버 클라우드 플랫폼 콘솔의 Classic 환경에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
- Backup 메뉴를 클릭해 주십시오.
- 상세 정보를 확인할 백업 설정 행의 상세정보 보기에서 [상세내역] 버튼을 클릭해 주십시오.
- 백업 파일의 상세 정보를 확인해 주십시오.
- Backup 날짜: 백업을 수행한 날짜
- Backup 시작시간: 백업 수행을 시작한 시각
- Backup 완료시간: 백업 수행을 완료한 시각
- 소요시간: 백업 수행이 완료되기까지 걸린 시간
- Backup 크기: 백업 수행 완료 후 생성된 백업 파일의 크기(MB)
- 데이터 스토리지: 해당 MySQL Server의 데이터 스토리지 크기
콘솔에서 데이터 복원
Cloud DB for MySQL에서는 백업 파일을 이용하여 소실된 데이터를 복원하여 쉽고 빠르게 MySQL Server를 생성할 수 있는 서비스를 제공하고 있습니다. 또한 시점 복원 기능을 사용하여 복원 가능한 시간 범위 내에서 사용자가 원하는 시간대로 데이터를 복원할 수 있습니다.
Backup 파일 복원
자동 백업을 통해 생성된 Backup 파일을 사용하여 데이터를 복원할 수 있습니다.
생성된 백업 파일을 사용하여 데이터를 복원하는 방법은 다음과 같습니다.
- 네이버 클라우드 플랫폼 콘솔의 Classic 환경에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
- Backup 메뉴를 클릭해 주십시오.
- 복원할 백업 설정 행의 [상세내역] 버튼을 클릭해 주십시오.
- 백업 파일을 선택한 후 [Backup 파일 복원] 버튼을 클릭해 주십시오.
- Backup 파일 복원 팝업 창이 나타나면 복원을 위해 필요한 정보를 확인하거나 입력해 주십시오.
- Backup 시간: 복원 가능한 시간 범위(최대 7일)
- Backup 완료 시간: 복원하고 싶은 시점
- DB Server 타입: 복원할 MySQL Server 타입
- DB Server 이름: 복원할 MySQL Server 이름
- [복원하기] 버튼 또는 [생성] 버튼을 클릭해 주십시오.
- [확인] 버튼을 클릭해 주십시오.
- DB Server 메뉴를 클릭해 주십시오.
- 복원 중인 서버의 상태를 확인해 주십시오.
- Recovery 타입으로 생성됨
- 생성중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하고 있는 상태
- 설정중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하여 구성하고 있는 상태
- 운영중: 사용자가 입력한 정보로 MySQL Server의 생성(복원)과 설정이 완료되어 애플리케이션 서버에서 MySQL Server에 접속 가능한 상태
서버 복원 완료까지 수 분이 소요될 수 있습니다.
시점 복원
원하는 특정 시점으로 데이터를 복원할 수 있습니다. 복원하는 시점은 복원 가능한 범위 내에서 분 단위까지 지정할 수 있습니다.
시점 복원 기능으로 데이터를 복원 방법은 다음과 같습니다.
Stand Alone 타입의 Server는 시점 복원 기능을 제공하지 않습니다.
- 네이버 클라우드 플랫폼 콘솔의 Classic 환경에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
- Backup 메뉴를 클릭해 주십시오.
- 복원할 백업 설정 행의 [상세내역] 버튼을 클릭해 주십시오.
- [시점 복원] 버튼을 클릭해 주십시오.
- 시점 복원 팝업 창이 나타나면 복원을 위해 필요한 정보를 확인하거나 입력해 주십시오.
- DB 복원 가능한 시간: 복원 가능한 시간 범위(최대 7일)
- DB 복원 시간: 복원하고 싶은 시점
- DB Server 타입: 복원할 MySQL Server 타입
- DB Server 이름: 복원할 MySQL Server 이름
- [복원하기] 버튼 또는 [생성] 버튼을 클릭해 주십시오.
- [확인] 버튼을 클릭해 주십시오.
- DB Server 메뉴를 클릭해 주십시오.
- 복원 중인 서버의 상태를 확인해 주십시오.
- Recovery 타입으로 생성됨
- 생성중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하고 있는 상태
- 설정중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하여 구성하고 있는 상태
- 운영중: 사용자가 입력한 정보로 MySQL Server의 생성(복원)과 설정이 완료되어 애플리케이션 서버에서 MySQL Server에 접속 가능한 상태
서버 복원 완료까지 수 분이 소요될 수 있습니다.
복원된 Server로 새 DB Service 생성
복원 기능을 통해 생성한 Recovery Server를 바탕으로 새 DB Service를 생성하고 해당 Server를 Stand Alone 또는 고가용성 구성 Server로 변경할 수 있습니다. Server의 사양, DB 설정, 백업 시간은 동일하게 유지됩니다. 백업 시간을 별도로 설정하지 않은 Server를 복원한 경우 보관일은 1일로 설정됩니다.
- 네이버 클라우드 플랫폼 콘솔의 Classic 환경에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
- DB Server 메뉴를 클릭해 주십시오.
- 새 DB Service를 생성할 Recovery Server를 클릭한 다음 [DB 관리] 버튼을 클릭해 주십시오.
- [신규 DB 서비스 생성] 버튼을 클릭해 주십시오.
- 신규 DB 서비스 생성 팝업 창이 나타나면 고가용성 지원 여부를 선택하고 DB 서비스 이름을 입력한 다음 [예] 버튼을 클릭해 주십시오.
- 생성 중인 서버의 상태를 확인해 주십시오.
- 생성중: 사용자가 입력한 정보로 MySQL Server를 생성하고 있는 상태
- 설정중: 사용자가 입력한 정보로 MySQL Server를 생성하여 구성하고 있는 상태
- 운영중: 사용자가 입력한 정보로 MySQL Server의 생성과 설정이 완료되어 애플리케이션 서버에서 MySQL Server에 접속 가능한 상태
Object Storage에 저장
Cloud DB for MySQL에서는 생성한 백업 파일을 Object Storage에 저장하여 백업 시 사용할 수 있습니다. 보관 중이던 백업 파일을 Object Storage에 저장하는 방법은 다음과 같습니다.
- Object Storage 이용 신청 시 별도의 요금이 부과됩니다. Object Storage 소개와 요금제에 대한 설명은 네이버 클라우드 플랫폼 포털의 서비스 > Storage > Object Storage 메뉴를 참고해 주십시오.
- Secure Zone에 생성된 MySQL Server의 경우 먼저 네이버 클라우드 Secure Zone에서 관련 Policy를 추가해야 합니다. Policy 생성 팝업창의 Source IP, Destination IP 항목에서 각각 MySQL 서버와 Object Storage를 선택해 주십시오. Secure Zone에 대한 자세한 설명은 Secure Zone을 참조해 주십시오.
- 네이버 클라우드 플랫폼 콘솔의 Classic 환경에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
- Backup 메뉴를 클릭해 주십시오.
- Object Storage에 저장할 파일이 있는 백업 설정 행의 [상세내역] 버튼을 클릭해 주십시오.
- 백업 파일을 선택한 후 [Object Storage로 보내기] 버튼을 클릭해 주십시오.
- Object Storage로 보내기 팝업 창이 나타나면 저장할 버킷을 클릭하여 선택해 주십시오.
- [Object Storage로 보내기] 버튼을 클릭해 주십시오.
- [확인] 버튼을 클릭해 주십시오.
- Object Storage로 보내기 시 버킷 잠금 해제와 적절한 접근제어와 ACL 설정이 필요합니다.
- Object Storage로 보내기 완료까지 수 분이 소요될 수 있습니다.
백업 유틸리티 사용
Percona Xtrabackup, mysqldump 유틸리티를 사용하여 MySQL Server의 데이터를 백업하고 복원할 수 있습니다.
Xtrabackup을 통한 백업 파일 복원
네이버 클라우드 플랫폼의 Object Storage에 백업 파일을 저장한 후 Xtrabackup을 사용하여 서버에서 데이터를 복원할 수 있습니다.
Object Storage에 저장한 백업 파일을 Xtrabackup을 통해서 복원하기 위해 갖추어야 하는 전제조건은 다음과 같습니다.
- 사용자의 별도 서버에 설치된 MySQL의 메이저 버전이 백업한 MySQL의 메이저 버전과 동일
- 백업 파일의 복원에 필요한 xtrabackup binary 존재
- 복원할 MySQL Server에
datadir
변수가 설정되어 있는 my.cnf 파일 존재 - 복원 명령을 수행하는 OS 사용자가
datadir
디렉터리에 접근 및 쓰기를 수행 가능 - 복원할 서버에서 MySQL이 Shutdown 상태
- 서버가 CentOS 이외의 OS를 사용하는 경우 다운로드 링크에서 사용 중인 OS 이미지에 맞는 Xtrabackup binary를 다운로드해 주십시오.
- Xtrabackup binary의 옵션에 대한 설명은 Percona 공식 문서(영문)을 참고해 주십시오.
Xtrabackup을 사용하여 데이터를 복원하려면 다음 단계를 차례대로 진행해 주십시오. CentOS 7.8 애플리케이션 서버를 기준으로 설명합니다.
1. Object Storage에서 백업 파일 준비
- Object Storage에 저장을 참조하여 복원하려는 MySQL Server의 백업 파일을 Object Storage에 저장해 주십시오.
- 네이버 클라우드 플랫폼 콘솔의 Classic 환경에서 Services > Storage > Object Storage > Bucket Management 메뉴를 차례대로 클릭한 후 백업 파일을 저장한 버킷을 클릭해 주십시오.
- 저장한 백업 파일을 클릭한 후 편집 > 권한 관리 메뉴를 차례대로 클릭해 주십시오.
- 전체 공개 항목을 공개로 변경한 후 [확인] 버튼을 클릭해 주십시오.
- 저장한 백업 파일의 상세 정보에서 Link 항목의 링크를 복사해 주십시오.
2. Xtrabackup을 사용하여 데이터 복원
- Cloud DB for MySQL 시작을 참조하여 애플리케이션 서버에 접속해 주십시오.
- MySQL 5.7 버전 Server인 경우 my.cnf 파일의
[mysqld]
구문 아래에innodb_undo_tablespaces = 2
구문을 추가해 주십시오.
- MySQL 5.7 버전 Server인 경우 my.cnf 파일의
- 아래 명령에 복사한 링크를 넣은 후 실행하여 백업 파일을 다운로드해 주십시오.
- 백업 파일 다운로드가 완료되면 Object Storage의 권한 관리에서 공개 설정을 공개 안함으로 변경해 주십시오.
# wget [Link] -- 예시 # wget https://kr.beta-object.ncloudstorage.com/mysql-b/20211013_BACKUP.1634094735
- 아래 명령을 차례대로 실행하여 Xtrabackup을 다운로드해 주십시오.
- MySQL 5.7 버전
# cd ~ # wget https://www.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.9/binary/tarball/percona-xtrabackup-2.4.9-Linux-x86_64.tar.gz # tar xzf percona-xtrabackup-2.4.9-Linux-x86_64.tar.gz # cd ./percona-xtrabackup-2.4.9-Linux-x86_64 # XTRABACKUP_DIR=`pwd`
- MySQL 8.0 버전
# cd ~ # wget https://downloads.percona.com/downloads/Percona-XtraBackup-8.0/Percona-XtraBackup-8.0.23-16/binary/tarball/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17.tar.gz # tar xzf percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17.tar.gz # cd ./percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17 # XTRABACKUP_DIR=`pwd`
- 아래 명령을 실행하여 my.cnf 파일의 절대 경로를 설정해 주십시오.
# MYSQL_CONF=/etc/my.cnf
- 아래 명령을 차례대로 실행하여 임시 디렉터리를 생성하고 백업 파일을 복사해 주십시오.
# cd ~ # mkdir backup # cd ./backup/ # cp ~/[백업 파일 이름] . -- 예시 # cp ~/20211013_BACKUP.1634094735 .
- 아래 명령을 차례대로 실행하여
BACKUP_DIR
의 경로를 임시 디렉터리 위치로 지정하고 각 경로가 정상적으로 지정되었는지 확인해 주십시오.# BACKUP_DIR=`pwd` # echo $XTRABACKUP_DIR # echo $MYSQL_CONF # echo $BACKUP_DIR
- 아래 명령을 차례대로 실행하여 실행 중인 MySQL을 종료하고
xbstream
으로부터 파일을 추출해 주십시오.# systemctl stop mysqld # cd $BACKUP_DIR # cat [업로드한_ 백업파일] | ${XTRABACKUP_DIR}/bin/xbstream -x -- 예시 # cat 20211013_BACKUP.1634094735 | ${XTRABACKUP_DIR}/bin/xbstream -x
- 아래 명령을 실행하여 생성한 임시 디렉터리에 백업 파일을 복원해 주십시오.
- MySQL 5.7 버전
# ${XTRABACKUP_DIR}/bin/innobackupex --defaults-file=${MYSQL_CONF} --apply-log ${BACKUP_DIR}/
- MySQL 8.0 버전
# ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --prepare --target-dir=${BACKUP_DIR}/
- my.cnf 파일을 열어 datadir의 위치를 확인한 후 아래 명령을 실행하여 datadir 변수에 해당하는 디렉터리를 다른 임시 백업 폴더로 이동해 주십시오.
# mv [data directory 위치] /[new_directory 위치] -- 예시 # mv /var/lib/mysql /new_directory
- 아래 명령을 실행하여 새로 생성한 MySQL 디렉터리에 백업 파일을 이동해 주십시오.
- MySQL 5.7 버전
# ${XTRABACKUP_DIR}/bin/innobackupex --defaults-file=${MYSQL_CONF} --move-back ${BACKUP_DIR}
- MySQL 8.0 버전
# ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --move-back --target-dir=${BACKUP_DIR}/
- 아래 명령을 차례대로 입력하여 datadir 위치로 이동한 후 datadir 권한을
mysql
로 변경해 주십시오.- 변경을 완료한 후
ll
명령어를 실행하여 권한이 정상적으로 변경되었는지 확인할 수 있습니다.
# cd /var/lib/mysql # chown -R mysql:mysql [data directory 경로] -- 예시 # chown -R mysql:mysql /var/lib/mysql
- 변경을 완료한 후
- my.cnf 파일의
[mysqld]
구문 아래에 'skip-grant-tables' 구문을 추가해 주십시오. - 아래 명령을 차례대로 실행하여 MySQL을 시작한 후 새 root 계정을 생성해 주십시오.
create
실행 시ERROR 1396 (HY000): Operation CREATE USER failed for 'root'@'localhost'
오류가 발생할 수 있습니다. 이 경우drop user 'root'@'localhost';
명령을 실행하여 기존 root 계정을 삭제한 후 다시create
를 실행해 주십시오.
# systemctl start mysqld mysql -u root -p mysql > flush privileges; mysql > create user root@localhost identified by '패스워드'; mysql > grant all privileges on *.* to root@localhost with grant option; mysql > flush privileges;
- my.cnf 파일의
[mysqld]
구문 아래에 추가한skip-grant-tables
구문을 삭제한 후 아래 명령을 실행하여 MySQL을 재시작해 주십시오.# systemctl restart mysqld
mysqldump를 통한 DB 백업 및 복원
mysqldump 유틸리티를 사용하여 애플리케이션 서버에서 MySQL Server의 백업 및 복원을 수행할 수 있습니다.
mysqldump를 통한 DB 백업
mysqldump 유틸리티를 사용하여 서버에서 DB를 백업하는 방법은 다음과 같습니다.
- Cloud DB for MySQL은 GTID(Global Transaction Identifier)를 사용하므로, GTID를 사용하지 않는 MySQL DB를 복구하려면 백업 수행 시
--set-gtid-purged=OFF
옵션을 추가해 주십시오. - 백업 수행 직후 Cloud DB for MySQL과의 Replication 연결을 하고자 할 경우 GTID를 사용할 수 있도록
--set-gtid-purged=OFF
옵션을 삭제해 주십시오. - Cloud DB for MySQL의 백업본을 또 다른 Cloud DB for MySQL 서비스로 복구할 경우
--set-gtid-purged=OFF
옵션을 활성화하고 사용자 DB에 한해서만 백업을 진행해 주십시오.
- Cloud DB for MySQL 시작을 참조하여 애플리케이션 서버에 접속해 주십시오.
- 아래 명령을 실행하여 원하는 DB를 백업해 주십시오.
User ID, 비밀번호, Private 도메인, DB명은 콘솔 DB Server 메뉴의 각 Server 상세 정보에서 확인할 수 있습니다.- 특정 DB만 백업
# mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Private 도메인] -S [mysql.sock 위치] --single-transaction --databases [백업할 데이터베이스명] > [생성할 백업 파일명].sql -- 예시 # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.beta-cdb.ntruss.com -S /var/lib/mysql/mysql.sock --single-transaction --databases dbdb > dumpfile.sql
- 전체 DB를 백업
--mysqldump 5.7 및 이하 버전 # mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Private 도메인] -S [mysql.sock 위치] --single-transaction --all-databases > [생성할 백업 파일명].sql -- 예시 # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.beta-cdb.ntruss.com -S /var/lib/mysql/mysql.sock --single-transaction --all-databases > dumpfile.sql --mysqldump 8.0 버전 # mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Private 도메인] -S [mysql.sock 위치] --single-transaction --column-statistics=0 --all-databases > [생성할 백업 파일명].sql -- 예시 # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.beta-cdb.ntruss.com -S /var/lib/mysql/mysql.sock --single-transaction --column-statistics=0 --all-databases > dumpfile.sql
mysqldump를 통한 백업 파일 복원
mysqldump 유틸리티를 사용하여 서버에서 백업 파일을 복원하는 방법은 다음과 같습니다.
- [Cloud DB for MySQL 시작](/docs/clouddbformysql-start-classic#애플리케이션서버접속테스트을 참조하여 애플리케이션 서버에 접속해 주십시오.
- 아래 명령을 실행하여 원하는 백업 파일을 복원해 주십시오.
# mysql -u root -p < [백업 파일명].sql
-- 예시
# mysql -u root -p < dumpfile.sql
-- `--set-gtid-purged=OFF` 옵션을 제외한 백업 파일로 복원을 수행할 때 `ERROR 3546 (HY000)` 오류가 발생하는 경우 먼저 아래 명령어를 차례대로 실행 후 복원 수행
# mysql -u root - p
mysql> reset master;
Replication 연결
Slave Server와 Master Server의 Replication 연결을 수행하고 연결 상태를 확인할 수 있습니다.
Replication 연결을 수행하는 방법은 다음과 같습니다.
Master Server는 Private 도메인을 사용하는 서버이며, Slave Server는 local 서버입니다.
- DB User 관리를 참조하여 Replication 연결에 사용할 사용자 계정을 생성해 주십시오.
- HOST(IP)에는 Slave Server가 위치한 애플리케이션 서버의 비공인 IP를 입력해 주십시오.
- 아래의 설정을 my.cnf 파일의
[mysqld]
구문 아래에 추가해 주십시오.server-id
는 Replication 구성 내에서 각 서버를 구분할 수 있도록 고유한 값으로 설정해야 하며, 1~4294967295 사이의 숫자만 입력할 수 있습니다.
# Replication server-id = 2 log-bin = mysql-bin relay-log = relay-bin report-host = ncp-mysql-server master_info_repository = FILE relay_log_info_repository = FILE slave_type_conversions = ALL_NON_LOSSY log_slave_updates # required! GTID read_only # required! # Replication GTID enforce-gtid-consistency # required! GTID gtid-mode = ON # required! GTID
- 아래 명령을 실행하여 MySQL을 재시작해 주십시오.
systemctl restart mysqld
- 백업 유틸리티 사용을 참조하여 DB를 백업해 주십시오.
- 아래 명령을 차례대로 실행하여 root 계정으로 Slave Server에 접속한 후 Master를 변경해 주십시오.
mysql -u root -p
mysql> CHANGE MASTER TO
MASTER_HOST = 'DB Private 도메인',
MASTER_USER = 'User_ID',
MASTER_PASSWORD = '사용자의 비밀번호',
MASTER_PORT = 3306,
MASTER_AUTO_POSITION = 1;
-- 예시
mysql> CHANGE MASTER TO
-> MASTER_HOST = 'db-1qv7d.beta-cdb.ntruss.com',
-> MASTER_USER = 'replication',
-> MASTER_PASSWORD = 'password1!',
-> MASTER_PORT = 3306,
-> MASTER_AUTO_POSITION = 1;
- 아래 명령을 실행하여 Slave Server에서 Master Server로 연결해 주십시오.
mysql> START SLAVE;
연결 확인
Replication 연결을 완료한 후 연결 상태를 확인하려면 아래 명령을 실행한 후 표를 참조해 주십시오.
mysql> show slave status \G;
항목 | 설명 |
---|---|
Slave_IO_State | Slave Server의 현재 상태 |
Master_Host | Slave Server가 연결된 Master Server의 호스트명 또는 IP주소 |
Master_User | Slave Server가 Master Server로 연결할 때 사용하는 사용자 계정 |
Master_Port | Slave Server가 Master Server로 연결한 포트 |
Connect_Retry | 연결이 끊어졌을 때 재시도하는 시간(기본값: 60초)CHANGE MASTER TO 명령을 통해 변경 가능 |
Master_Log_File | I/O 스레드가 현재 읽고 있는 Master Server의 바이너리 로그 파일명 |
Read_Master_Log_Pos | I/O 스레드가 현재 읽고 있는 Master Server의 바이너리 로그 파일의 위치 |
Relay_Log_File | SQL 스레드가 현재 읽고 있는 Slave Server의 릴레이 로그 파일명 |
Relay_Log_Pos | SQL 스레드가 현재 읽고 있는 Slave Server의 릴레이 로그 파일의 위치 |
Relay_Master_Log_File | SQL 스레드에서 실행한 최신 이벤트가 포함된 소스 바이너리 로그 파일명 |
Slave_IO_Running | Slave Server의 I/O 스레드 동작 상태로, 다음 세 가지 값 중 하나를 통해 Master Server와의 연결 여부를 표시No : 스레드가 실행되지 않음Connecting : 스레드 실행 중, Master Server에 연결되지 않음Yes : 스레드 실행 중, Master Server에 연결됨 |
Slave_SQL_Running | SQL 스레드가 시작되었는지 표시 |
Replicate_Do_DB | --replicate-do-db 옵션으로 지정된 DB 목록 |
Replicate_Ignore_DB | --replicate-ignore-db 옵션으로 지정된 데이터베이스 목록 |
Replicate_Do_Table | --replicate-do-table 옵션으로 지정된 데이터베이스 목록 |
Replicate_Ignore_Table | --replicate-ignore-table 옵션으로 지정된 데이터베이스 목록 |
Replicate_Wild_Do_Table | --replicate-wild-do-table 옵션으로 지정된 데이터베이스 목록 |
Replicate_Wild_Ignore_Table | --replicate-wild-ignore-table_Table 옵션으로 지정된 데이터베이스 목록 |
Last_Errno , Last_Error | Last_SQL_Errno 항목과 같은 값으로, RESET MASTER , RESET SLAVE 명령으로 값 재설정 가능(Slave Server의 SQL 스레드가 오류를 전달받았을 때 해당 오류를 먼저 보고한 후 SQL 스레드를 정지시키므로, SHOW SLAVE STATUS 명령을 실행했을 때 Slave_SQL_Running 의 값이 YES 이더라도 이 항목의 값이 0 으로 나타나지 않음) |
Skip_Counter | 시스템 변수인 SQL_Slave_Skip_Counter 의 현재 값을 표시 |
Exec_Master_Log_Pos | SQL 스레드가 읽고 실행한 현재 Master Server의 바이너리 로그 파일 위치로, 다음에 처리될 트랜잭션 또는 이벤트의 시작을 표시 (새로운 Slave Server를 연결할 때 CHANGE MASTER TO 명령어에서 MASTER_LOG_POS 옵션에 값을 지정하면 연결한 Slave Server가 해당 지점부터 읽기 시작) |
Relay_Log_Space | 존재하는 모든 릴레이 로그 파일의 크기를 합친 값 |
Until_Condition | START_SLAVE 명령어에 지정된 값으로, 다음 값 중 하나로 표시None : UNTIL 절이 지정되지 않음Master : Slave Server가 Master Server의 바이너리 로그 파일을 설정함Relay : Slave Server가 릴레이 로그 파일을 설정함 |
Until_Log_File | SQL 스레드가 실행하였다가 중단할 로그 파일의 이름 |
Until_Log_Pos | SQL 스레드가 실행하였다가 중단할 로그 파일의 포지션 값 |
Master_SSL_Allowed | Slave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터로, 다음 값 중 하나로 표시Yes : SSL 연결 허용No : SSL 연결 허용 안 함Ignored : SSL 연결이 허용되지만 Slave Server에 SSL 지원이 활성화되어 있지 않음 |
Master_SSL_CA_File | Slave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터 |
Master_SSL_CA_Path | Slave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터 |
Master_SSL_Cert | Slave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터 |
Master_SSL_Cipher | Slave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터 |
Master_SSL_Key | Slave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터 |
Seconds_Behind_Master | Slaver Server의 복제 속도가 어느 정도 느려졌는지 표시 |
Master_SSL_Verify_Server_Cert | Slave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터 |
Last_IO_Errno | 가장 최근에 I/O 스레드를 멈추게 한 오류 번호 |
Last_IO_Error | 가장 최근에 I/O 스레드를 멈추게 한 오류 메시지 |
Last_SQL_Errno | 가장 최근에 SQL 스레드를 멈추게 한 오류 번호 |
Last_SQL_Error | 가장 최근에 SQL 스레드를 멈추게 한 오류 메시지 |
Replicate_Ignore_Server_Ids | Slave Server에서 CHANGE MASTER TO 구문의 IGNOER_SERVER_IDS 옵션을 실행한 내용 |
Master_Server_Id | Master Server의 server_id 값 |
Master_UUID | Master Server의 server_uuid 값 |
Master_Info_File | master.info 파일의 위치 |
SQL_Delay | Slave Server가 Master Server와의 복제를 몇 초 지연시키는지 표시 |
SQL_Remaining_Delay | Slave_SQL_Running_State 가 Waiting until MASTER_DELAY seconds after master executed event 일 때의 남은 시간을 표시(이외의 경우에는 NULL ) |
Slave_SQL_Running_State | SQL 스레드의 동작 상태 |
Master_Retry_Count | Slave Server와 Master Server의 연결이 끊어졌을 때 재접속을 시도하는 횟수 |
Master_Bind | Slave Server가 바인딩된 네트워크 인터페이스 |
Last_IO_Error_Timestamp | 최근에 발생한 I/O 오류의 발생 시각 (YYMMDD HH:MM:SS) |
Last_SQL_Error_Timestamp | 최근에 발생한 SQL 오류의 발생 시각 (YYMMDD HH:MM:SS) |
Retrieved_Gtid_Set | Slave Server가 받은 모든 트랜잭션에 상응하는 GTID 집합 (GTID를 사용하지 않는 경우 공백) |
Executed_Gtid_Set | 바이너리 로그에 작성된 GTID 집합 (GTID를 사용하지 않는 경우 공백) |
Auto_Position | Auto_Position 사용 시 1 , 미사용 시 0 |
Replication 오류 해결
Master Server와 Slave Server의 Executed_Gtid_Set
값이 서로 동일하지 않으면 show slave status \G;
명령으로 연결 상태를 확인했을 때 Slave_SQL_Running
과 Slave_IO_Running
중 하나의 값이 No
로 표시되며, 아래와 같은 오류가 표시될 수 있습니다.
Slave_SQL_Running: No
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'e0b74649-41d7-11ec-afb6-f220af895dd6:2' at master log mysql-bin.000001, end_log_pos 751. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Slave_IO_Running: No
Last_IO_Error: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period.
Executed_Gtid_Set
값을 수정하여 Replication 오류를 해결하는 방법은 다음과 같습니다.
GTID_PURGED
값 재설정 시 데이터 불일치가 발생하지 않도록 MySQL 공식 문서와 Percona 공식 문서를 참고해 주십시오.
- 아래 명령어를 각각 실행하여 Master Server와 Slave Server의
Executed_Gtid_Set
값이 서로 동일한지 확인해 주십시오.- Master Server:
show global variables like 'gtid_executed';
- Slave Server:
show slave status \G;
- Master Server:
- 아래 명령어를 실행하여
GTID_PURGED
값을 재설정해 주십시오.① GTID_PURGED 재설정 mysql> stop slave; mysql> reset master; mysql> set global GTID_PURGED="마스터 Executed_Gtid_Set값"; mysql> start slave; ② root 계정 재설정 mysql> flush privileges; mysql> create user root@localhost identified by '패스워드'; mysql> grant all privileges on *.* to root@localhost with grant option; mysql> flush privileges;