Backup
    • PDF

    Backup

    • PDF

    기사 요약

    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 이용을 위한 기본적인 설명은 다음과 같습니다.

    database-database-5-4_main_vpc_ko.png

    영역설명
    ① 메뉴 이름현재 확인 중인 메뉴 이름
    ② 기본 기능Cloud DB for MySQL 상세 정보 확인, Backup 화면 새로 고침
    ③ 백업 목록설정해놓은 서버별 백업 설정 및 설정 정보

    백업 설정 목록 확인

    운영 중인 MySQL Server 별 백업 설정 목록을 확인할 수 있습니다. 백업 설정 목록을 확인하는 방법은 다음과 같습니다.

    1. 네이버 클라우드 플랫폼 콘솔에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
    2. Backup 메뉴를 클릭해 주십시오.
    3. 백업 설정 목록이 나타나면 필요한 정보를 확인해 주십시오.
      database-database-5-4_backuplistdetails_vpc_ko.png
      • DB 서비스 이름: 사용자가 지정한 DB Service 이름
      • Backup 보관일: 백업 파일을 데이터 스토리지에 저장하여 보관하는 최대 일수
      • Backup 시작시간: 매일 1회 백업을 수행하는 시간
      • Backup 데이터 크기: 완료된 백업 파일의 크기
      • 마지막 Backup 일시: 최근에 수행 완료한 백업 날짜
      • 상세정보 보기: 서버별 생성된 백업 파일 목록의 상세 정보 및 복원, Object Storage에 저장

    서버별 백업 파일 목록 확인

    백업 수행을 완료하여 서버별로 생성된 백업 파일 목록을 확인하는 방법은 다음과 같습니다.

    1. 네이버 클라우드 플랫폼 콘솔에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
    2. Backup 메뉴를 클릭해 주십시오.
    3. 상세 정보를 확인할 백업 설정 행의 상세정보 보기에서 [상세내역] 버튼을 클릭해 주십시오.
    4. 백업 파일의 상세 정보를 확인해 주십시오.
      database-database-5-4_backupdetails_vpc_ko.png
      • Backup 날짜: 백업을 수행한 날짜
      • Backup 시작시간: 백업 수행을 시작한 시각
      • Backup 완료시간: 백업 수행을 완료한 시각
      • 소요시간: 백업 수행이 완료되기까지 걸린 시간
      • Backup 크기: 백업 수행 완료 후 생성된 백업 파일의 크기(MB)
      • 데이터 스토리지: 해당 MySQL Server의 데이터 스토리지 크기

    콘솔에서 데이터 복원

    Cloud DB for MySQL에서는 백업 파일을 이용하여 소실된 데이터를 복원하여 쉽고 빠르게 MySQL Server를 생성할 수 있는 서비스를 제공하고 있습니다. 또한 시점 복원 기능을 사용하여 복원 가능한 시간 범위 내에서 사용자가 원하는 시간대로 데이터를 복원할 수 있습니다.

    Backup 파일 복원

    자동 백업을 통해 생성된 Backup 파일을 사용하여 데이터를 복원할 수 있습니다.

    생성된 백업 파일을 사용하여 데이터를 복원하는 방법은 다음과 같습니다.

    1. 네이버 클라우드 플랫폼 콘솔에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
    2. Backup 메뉴를 클릭해 주십시오.
    3. 복원할 백업 설정 행의 [상세내역] 버튼을 클릭해 주십시오.
    4. 백업 파일을 선택한 후 [Backup 파일 복원] 버튼을 클릭해 주십시오.
    5. Backup 파일 복원 팝업 창이 나타나면 복원을 위해 필요한 정보를 확인하거나 입력해 주십시오.
      database-database-5-4_restorepopup_vpc_ko.png
      • Backup 시간: 복원 가능한 시간 범위(최대 7일)
      • Backup 완료 시간: 복원하고 싶은 시점
      • Private Sub 도메인 (VPC 환경): 복원할 서버에서 사용할 Private Sub 도메인(선택 불가)
      • DB Server 타입: 복원할 MySQL Server 타입
      • DB Server 이름: 복원할 MySQL Server 이름
      • 신규 DB 서비스로 생성 : 복원할 서버를 신규 서비스로 생성
      • DB 서비스 이름 : 신규 DB 서비스 이름
      • 고가용성: 신규 서비스 생성 시 고가용성 구성으로 생성
      • Multi Zone: 서로 다른 가용영역에 Standby Master Server와 Master Server 생성
      • Subnet: Master Subnet 과 다른 가용 영역의 서브넷
    6. [복원하기] 버튼 또는 [생성] 버튼을 클릭해 주십시오.
    7. [확인] 버튼을 클릭해 주십시오.
    8. DB Server 메뉴를 클릭해 주십시오.
    9. 복원 중인 서버의 상태를 확인해 주십시오.
      • Recovery 타입으로 생성됨
      • 생성중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하고 있는 상태
      • 설정중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하여 구성하고 있는 상태
      • 운영중: 사용자가 입력한 정보로 MySQL Server의 생성(복원)과 설정이 완료되어 애플리케이션 서버에서 MySQL Server에 접속 가능한 상태
    주의

    서버 복원 완료까지 수 분이 소요될 수 있습니다.

    시점 복원

    원하는 특정 시점으로 데이터를 복원할 수 있습니다. 복원하는 시점은 복원 가능한 범위 내에서 분 단위까지 지정할 수 있습니다.

    시점 복원 기능으로 데이터를 복원 방법은 다음과 같습니다.

    참고

    Stand Alone 타입의 Server는 시점 복원 기능을 제공하지 않습니다.

    1. 네이버 클라우드 플랫폼 콘솔에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.

    2. Backup 메뉴를 클릭해 주십시오.

    3. 복원할 백업 설정 행의 [상세내역] 버튼을 클릭해 주십시오.

    4. [시점 복원] 버튼을 클릭해 주십시오.
      database-database-5-4_restorepointhover_vpc_ko.png

    5. 시점 복원 팝업 창이 나타나면 복원을 위해 필요한 정보를 확인하거나 입력해 주십시오.
      database-database-5-4_restorepoint_vpc_ko.png

      • DB 복원 가능한 시간: 복원 가능한 시간 범위(최대 7일)
      • DB 복원 시간: 복원하고 싶은 시점
      • Private Sub 도메인 (VPC 환경): 복원할 서버에서 사용할 Private Sub 도메인(선택 불가)
      • DB Server 타입: 복원할 MySQL Server 타입
      • DB Server 이름: 복원할 MySQL Server 이름
    6. [복원하기] 버튼 또는 [생성] 버튼을 클릭해 주십시오.

    7. [확인] 버튼을 클릭해 주십시오.

    8. DB Server 메뉴를 클릭해 주십시오.

    9. 복원 중인 서버의 상태를 확인해 주십시오.

      • Recovery 타입으로 생성됨
      • 생성중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하고 있는 상태
      • 설정중: 사용자가 입력한 정보로 MySQL Server를 생성(복원)하여 구성하고 있는 상태
      • 운영중: 사용자가 입력한 정보로 MySQL Server의 생성(복원)과 설정이 완료되어 애플리케이션 서버에서 MySQL Server에 접속 가능한 상태
    주의

    서버 복원 완료까지 수 분이 소요될 수 있습니다.

    복원된 Server로 새 DB Service 생성

    복원 기능을 통해 생성한 Recovery Server를 바탕으로 새 DB Service를 생성하고 해당 Server를 Stand Alone 또는 고가용성 구성 Server로 변경할 수 있습니다. Server의 사양, DB 설정, 백업 시간은 동일하게 유지됩니다. 백업 시간을 별도로 설정하지 않은 Server를 복원한 경우 보관일은 1일로 설정됩니다.

    참고

    데이터 스토리지 암호화된 Recovery Server는 고가용성 구성의 DB Service만 생성할 수 있습니다.

    1. 네이버 클라우드 플랫폼 콘솔에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
    2. DB Server 메뉴를 클릭해 주십시오.
    3. 새 DB Service를 생성할 Recovery Server를 클릭한 다음 [DB 관리] 버튼을 클릭해 주십시오.
    4. [신규 DB 서비스 생성] 버튼을 클릭해 주십시오.
    5. 신규 DB 서비스 생성 팝업 창이 나타나면 고가용성 지원 여부를 선택하고 DB 서비스 이름을 입력한 다음 [예] 버튼을 클릭해 주십시오.
      database-database-5-4_newService_vpc_ko.png
    6. 생성 중인 서버의 상태를 확인해 주십시오.
      • 생성중: 사용자가 입력한 정보로 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 메뉴를 참고해 주십시오.

    1. 네이버 클라우드 플랫폼 콘솔에서 Services > Database > Cloud DB for MySQL 메뉴를 차례대로 클릭해 주십시오.
    2. Backup 메뉴를 클릭해 주십시오.
    3. Object Storage에 저장할 파일이 있는 백업 설정 행의 [상세내역] 버튼을 클릭해 주십시오.
    4. 백업 파일을 선택한 후 [Object Storage로 보내기] 버튼을 클릭해 주십시오.
      database-database-5-4_objhover_vpc_ko.png
    5. Object Storage로 보내기 팝업 창이 나타나면 저장할 버킷과 폴더를 클릭하여 선택해 주십시오.
      database-database-5-4_objpopup_vpc_ko.png
    6. [Object Storage로 보내기] 버튼을 클릭해 주십시오.
    7. [확인] 버튼을 클릭해 주십시오.
    참고
    • 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를 다운로드해 주십시오. MySQL 8.0 이상 버전을 사용하는 경우, 복원하려는 MySQL 버전과 동일한 버전의 Xtrabackup을 다운로드해 주십시오.
    • Xtrabackup binary의 옵션에 대한 설명은 Percona 공식 문서(영문)을 참고해 주십시오.

    Xtrabackup을 사용하여 데이터를 복원하려면 다음 단계를 차례대로 진행해 주십시오. CentOS 7.8 애플리케이션 서버를 기준으로 설명합니다.

    1. Object Storage에서 백업 파일 준비

    1. Object Storage에 저장을 참조하여 복원하려는 MySQL Server의 백업 파일을 Object Storage에 저장해 주십시오.
    2. 네이버 클라우드 플랫폼 콘솔에서 Services > Storage > Object Storage > Bucket Management 메뉴를 차례대로 클릭한 후 백업 파일을 저장한 버킷을 클릭해 주십시오.
    3. 저장한 백업 파일을 클릭한 후 편집 > 권한 관리 메뉴를 차례대로 클릭해 주십시오.
    4. 전체 공개 항목을 공개로 변경한 후 [확인] 버튼을 클릭해 주십시오.
    5. 저장한 백업 파일의 상세 정보에서 Link 항목의 링크를 복사해 주십시오.

    2. Xtrabackup을 사용하여 데이터 복원

    1. Cloud DB for MySQL 시작을 참조하여 애플리케이션 서버에 접속해 주십시오.
      • MySQL 5.7 버전 Server인 경우 my.cnf 파일의 [mysqld] 구문 아래에 innodb_undo_tablespaces = 2 구문을 추가해 주십시오.
      # vi /etc/my.cnf
      
      [mysqld]
      innodb_undo_tablespaces = 2
      
    2. 아래 명령에 복사한 링크를 넣은 후 실행하여 백업 파일을 다운로드해 주십시오.
      • 백업 파일 다운로드가 완료되면 Object Storage의 권한 관리에서 공개 설정을 공개 안함으로 변경해 주십시오.
      # wget [Link]
      
      -- 예시
      # wget https://kr.beta-object.ncloudstorage.com/mysql-b/20211013_BACKUP.1634094735
      
    3. 아래 명령을 차례대로 실행하여 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`
      
    4. 아래 명령을 실행하여 my.cnf 파일의 절대 경로를 설정해 주십시오.
      # MYSQL_CONF=/etc/my.cnf
      
    5. 아래 명령을 차례대로 실행하여 임시 디렉터리를 생성하고 백업 파일을 복사해 주십시오.
      # cd ~
      
      # mkdir backup
      
      # cd ./backup/
      
      # cp ~/[백업 파일 이름] .
      
      -- 예시
      # cp ~/20211013_BACKUP.1634094735 .
      
    6. 아래 명령을 차례대로 실행하여 BACKUP_DIR의 경로를 임시 디렉터리 위치로 지정하고 각 경로가 정상적으로 지정되었는지 확인해 주십시오.
      # BACKUP_DIR=`pwd`
      
      # echo $XTRABACKUP_DIR
      
      # echo $MYSQL_CONF
      
      # echo $BACKUP_DIR
      
    7. 아래 명령을 차례대로 실행하여 실행 중인 MySQL을 종료하고 xbstream으로부터 파일을 추출해 주십시오.
      # systemctl stop mysqld
      
      # cd $BACKUP_DIR
      
      # cat [업로드한_ 백업파일] | ${XTRABACKUP_DIR}/bin/xbstream -x
      
      -- 예시
      # cat 20211013_BACKUP.1634094735 | ${XTRABACKUP_DIR}/bin/xbstream -x
      
    8. 아래 명령을 실행하여 생성한 임시 디렉터리에 백업 파일을 복원해 주십시오.
      • 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}/
      
    9. my.cnf 파일을 열어 datadir의 위치를 확인한 후 아래 명령을 실행하여 datadir 변수에 해당하는 디렉터리를 다른 임시 백업 폴더로 이동해 주십시오.
      # mv [data directory 위치] /[new_directory 위치]
      
      -- 예시
      # mkdir /new_directory
      # mv /var/lib/mysql /new_directory
      
    10. 아래 명령을 실행하여 새로 생성한 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}/
      
    11. 아래 명령을 차례대로 입력하여 datadir 위치로 이동한 후 datadir 권한을 mysql로 변경해 주십시오.
      • 변경을 완료한 후 ll 명령어를 실행하여 권한이 정상적으로 변경되었는지 확인할 수 있습니다.
      # cd /var/lib/mysql
      
      # chown -R mysql:mysql [data directory 경로]
      
      -- 예시
      # chown -R mysql:mysql /var/lib/mysql
      
    12. my.cnf 파일의 [mysqld] 구문 아래에 'skip-grant-tables' 구문을 추가해 주십시오.
      # vi /etc/my.cnf
      
      [mysqld]
      skip-grant-tables
      
    13. 아래 명령을 차례대로 실행하여 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;
      
    14. 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에 한해서만 백업을 진행해 주십시오.
    1. Cloud DB for MySQL 시작을 참조하여 애플리케이션 서버에 접속해 주십시오.
    2. 아래 명령을 실행하여 원하는 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 유틸리티를 사용하여 서버에서 백업 파일을 복원하는 방법은 다음과 같습니다.

    1. Cloud DB for MySQL 시작을 참조하여 애플리케이션 서버에 접속해 주십시오.
    2. 아래 명령을 실행하여 원하는 백업 파일을 복원해 주십시오.
    # 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 서버입니다.

    1.DB User 관리를 참조하여 Replication 연결에 사용할 사용자 계정을 생성해 주십시오.

    • HOST(IP)에는 Slave Server가 위치한 애플리케이션 서버의 비공인 IP를 입력해 주십시오.
    1. 아래의 설정을 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 
      
    2. 아래 명령을 실행하여 MySQL을 재시작해 주십시오.
      systemctl restart mysqld
      
    3. 백업 유틸리티 사용을 참조하여 DB를 백업해 주십시오.
    4. 아래 명령을 차례대로 실행하여 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;
    
    1. 아래 명령을 실행하여 Slave Server에서 Master Server로 연결해 주십시오.
    mysql> START SLAVE;
    

    연결 확인

    Replication 연결을 완료한 후 연결 상태를 확인하려면 아래 명령을 실행한 후 표를 참조해 주십시오.

    mysql> show slave status \G;
    
    항목설명
    Slave_IO_StateSlave Server의 현재 상태
    Master_HostSlave Server가 연결된 Master Server의 호스트명 또는 IP주소
    Master_UserSlave Server가 Master Server로 연결할 때 사용하는 사용자 계정
    Master_PortSlave Server가 Master Server로 연결한 포트
    Connect_Retry연결이 끊어졌을 때 재시도하는 시간(기본값: 60초)
    CHANGE MASTER TO 명령을 통해 변경 가능
    Master_Log_FileI/O 스레드가 현재 읽고 있는 Master Server의 바이너리 로그 파일명
    Read_Master_Log_PosI/O 스레드가 현재 읽고 있는 Master Server의 바이너리 로그 파일의 위치
    Relay_Log_FileSQL 스레드가 현재 읽고 있는 Slave Server의 릴레이 로그 파일명
    Relay_Log_PosSQL 스레드가 현재 읽고 있는 Slave Server의 릴레이 로그 파일의 위치
    Relay_Master_Log_FileSQL 스레드에서 실행한 최신 이벤트가 포함된 소스 바이너리 로그 파일명
    Slave_IO_RunningSlave Server의 I/O 스레드 동작 상태로, 다음 세 가지 값 중 하나를 통해 Master Server와의 연결 여부를 표시
  • No: 스레드가 실행되지 않음
  • Connecting: 스레드 실행 중, Master Server에 연결되지 않음
  • Yes: 스레드 실행 중, Master Server에 연결됨
  • Slave_SQL_RunningSQL 스레드가 시작되었는지 표시
    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_ErrorLast_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_PosSQL 스레드가 읽고 실행한 현재 Master Server의 바이너리 로그 파일 위치로 다음에 처리될 트랜잭션 또는 이벤트의 시작을 표시
    (새로운 Slave Server를 연결할 때 CHANGE MASTER TO 명령어에서 MASTER_LOG_POS 옵션에 값을 지정하면 연결한 Slave Server가 해당 지점부터 읽기 시작)
    Relay_Log_Space존재하는 모든 릴레이 로그 파일의 크기를 합친 값
    Until_ConditionSTART_SLAVE 명령어에 지정된 값으로 다음 값 중 하나로 표시
  • None: UNTIL 절이 지정되지 않음
  • Master: Slave Server가 Master Server의 바이너리 로그 파일을 설정함
  • Relay: Slave Server가 릴레이 로그 파일을 설정함
  • Until_Log_FileSQL 스레드가 실행하였다가 중단할 로그 파일의 이름
    Until_Log_PosSQL 스레드가 실행하였다가 중단할 로그 파일의 포지션 값
    Master_SSL_AllowedSlave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터로 다음 값 중 하나로 표시
  • Yes: SSL 연결 허용
  • No: SSL 연결 허용 안 함
  • Ignored: SSL 연결이 허용되지만 Slave Server에 SSL 지원이 활성화되어 있지 않음
  • Master_SSL_CA_FileSlave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터
    Master_SSL_CA_PathSlave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터
    Master_SSL_CertSlave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터
    Master_SSL_CipherSlave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터
    Master_SSL_KeySlave Server가 Master Server로 연결할 때 사용되는 SSL 파라미터
    Seconds_Behind_MasterSlaver Server의 복제 속도가 어느 정도 느려졌는지 표시
    Master_SSL_Verify_Server_CertSlave 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_IdsSlave Server에서 CHANGE MASTER TO 구문의 IGNOER_SERVER_IDS 옵션을 실행한 내용
    Master_Server_IdMaster Server의 server_id
    Master_UUIDMaster Server의 server_uuid
    Master_Info_Filemaster.info 파일의 위치
    SQL_DelaySlave Server가 Master Server와의 복제를 몇 초 지연시키는지 표시
    SQL_Remaining_DelaySlave_SQL_Running_StateWaiting until MASTER_DELAY seconds after master executed event 일 때의 남은 시간을 표시
    (이외의 경우에는 NULL)
    Slave_SQL_Running_StateSQL 스레드의 동작 상태
    Master_Retry_CountSlave Server와 Master Server의 연결이 끊어졌을 때 재접속을 시도하는 횟수
    Master_BindSlave Server가 바인딩된 네트워크 인터페이스
    Last_IO_Error_Timestamp최근에 발생한 I/O 오류의 발생 시각
    (YYMMDD HH:MM:SS)
    Last_SQL_Error_Timestamp최근에 발생한 SQL 오류의 발생 시각
    (YYMMDD HH:MM:SS)
    Retrieved_Gtid_SetSlave Server가 받은 모든 트랜잭션에 상응하는 GTID 집합
    (GTID를 사용하지 않는 경우 공백)
    Executed_Gtid_Set바이너리 로그에 작성된 GTID 집합
    (GTID를 사용하지 않는 경우 공백)
    Auto_PositionAuto_Position 사용 시 1, 미사용 시 0

    Replication 오류 해결

    Master Server와 Slave Server의 Executed_Gtid_Set 값이 서로 동일하지 않으면 show slave status \G; 명령으로 연결 상태를 확인했을 때 Slave_SQL_RunningSlave_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 공식 문서를 참고해 주십시오.

    1. 아래 명령어를 각각 실행하여 Master Server와 Slave Server의 Executed_Gtid_Set 값이 서로 동일한지 확인해 주십시오.
      • Master Server: show global variables like 'gtid_executed';
      • Slave Server: show slave status \G;
    2. 아래 명령어를 실행하여 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;
      

    이 문서가 도움이 되었습니까?

    What's Next
    Changing your password will log you out immediately. Use the new password to log back in.
    First name must have atleast 2 characters. Numbers and special characters are not allowed.
    Last name must have atleast 1 characters. Numbers and special characters are not allowed.
    Enter a valid email
    Enter a valid password
    Your profile has been successfully updated.