Chat now with support
Chat with Support

NetVault Plug-in for MySQL 12.2 - 사용자 안내서

MySQL용 NetVault Backup 플러그인- 소개 플러그인 설치 및 제거 플러그인 구성 데이터 백업 데이터 복원 기본 MySQL 복제 작업 장애 조치 클러스터 환경에서 플러그인 사용 문제 해결

직업 마무리 및 제출

마지막 단계에는 일정, 소스 옵션 및 고급 옵션 페이지에 대한 추가 옵션 설정, 작업 제출 및 작업 상태와 로그 보기 페이지를 통한 진행 상태 모니터링이 포함됩니다. 이러한 페이지 및 옵션은 모든 NetVault Backup 플러그인에 공통입니다. 자세한 내용은 Quest NetVault Backup 관리자 안내서를 참조하십시오.

1
설정을 저장하려면 확인을 클릭 한 후 다음을 클릭합니다.
2
기본 설정을 사용하지 않으려는 경우 작업 이름에 작업의 이름을 지정합니다.
중요: 대상 OS의 파일 이름에 지원되지 않는 특수 문자를 사용하지 마십시오. 예를 들어 /,\,*, @ 문자는 Windows에서 사용할 수 없습니다. 이 요구 사항은 MySQL용 플러그인‑이 데이터를 임시로 복원하기 위해 작업 제목과 동일한 이름의 폴더를 생성하려고 하기 때문입니다.
3
대상 클라이언트 목록에서 데이터를 복원할 시스템을 선택합니다.
팁 : 선택을 클릭한 다음 대상 클라이언트 선택 대화 상자에서 해당 클라이언트를 찾아 선택합니다.
4
일정, 소스 옵션고급 옵션 목록을 사용하여 필요한 추가 옵션을 구성합니다.
5
해당되는 경우 저장 또는 저장 및 제출을 클릭합니다.
작업 상태 페이지에서 진행률을 모니터링하고 로그 보기 페이지에서 로그를 볼 수 있습니다. 자세한 내용은 Quest NetVault Backup 관리자 안내서를 참조하십시오.
중요: Linux 또는 UNIX 환경에서 MySQL Enterprise Backup을 사용하는 경우 복원된 데이터에 대한 파일 소유권 및 권한 정보가 데이터 백업 전의 정보와 일치하는지 확인하십시오. mysqlbackup 유틸리티에서 백업 프로세스 중에 이 정보를 기록하지 않으므로 복원이 완료된 후에 해당 정보가 다를 수 있습니다. 자세한 내용은 https://docs.oracle.com/cd/E17952_01/mysql-enterprise-backup-3.11-en/bugs.backup.html 페이지를 참조하십시오.

MySQL Standard/Community 복원 시나리오 예시

실패 또는 데이터 손상에서 성공적으로 복구하려면 복원을 위해 선택한 데이터 및 옵션 탭에서 사용 가능한 옵션과 관련하여 작업을 설정할 때 다양한 설정을 수행해야 합니다. 다음 항목에서는 다양한 복구 유형의 예시를 제공하고 필요한 특정 옵션을 다룹니다.

전체 백업 전용 복원 시나리오

다음 예에서 MySQL DBA는 매일 오후 11시에 전체 백업을 수행하는 백업 정책을 설정했습니다.

DBA는 월요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 자신이 작업장에 도착하기 전인 월요일 오전 6시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

방법 1: 오류 문 이전으로 복구

DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 이 결정은 DBA가 일요일의 전체 백업을 복원하고 현재 바이너리 로그에서 PIT 복구를 수행해야 함을 의미합니다.

1
일요일 밤에 수행된 전체 복원 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
현재 바이너리 로그에서 PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
시간 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 날짜/시간"5:59""8 Jan 2007"로 설정합니다. 즉, 월요일 오전 6시의 1분 전입니다.
방법 2: 오류 문 이전이후로 복원

DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 또한 DBA는 오류 문이 실행된 시점 이후부터 현재의 바이너리 로그가 끝날 때까지 나머지 테이블에 발생한 트랜잭션을 복구하려고 합니다. 이러한 결정을 통해 삭제된 테이블을 복구하는 것 외에도 가능한 한 많은 트랜잭션을 복구할 수 있습니다.

1
일요일 밤에 수행된 전체 복원 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
현재 바이너리 로그에서 PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
시간 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 날짜/시간"5:59""8 Jan 2007"로 설정합니다. 즉, 월요일 오전 6시의 1분 전입니다.
오류/잘못된 SQL 문 이후로 복구 활성화: 주문 테이블이 삭제된 이후에 발생한 트랜잭션을 복구하도록 선택하고 이후 시간과 날짜를 시작 날짜/시간에 입력했습니다. 마지막으로, 명명된 바이너리 로그 마지막까지 복구를 수행하기 때문에 중지 날짜/시간에 대해 없음 옵션이 선택되었습니다.

DBA는 월요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 자신이 작업장에 도착하기 전인 월요일 오전 6시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

방법 1: 오류 문 이전으로 복구

DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 또한 DBA는 개발자가 테이블을 삭제한 예측 시간보다 더 정확한 복구를 원하므로 위치 기반 복구를 사용하도록 선택합니다. 이 프로세스를 실행하려면 DBA가 일요일의 전체 백업을 복원하고 현재 바이너리 로그에서 PIT 복구를 수행해야 함을 의미합니다.

1
현재 바이너리 로그에 mysqlbinlog 유틸리티 사용: 이 단계는 NetVault Backup 외부에서 수행되어 DBA가 복원하지 않으려는 Drop Table 명령의 위치를 식별할 수 있습니다. (이 유틸리티 및 프로세스에 대한 자세한 내용은 MySQL 참조 안내서를 참조하십시오.) 이 프로세스에서 DBA는 Drop Table 명령을 "MYSQLSVR-bin.000009" 바이너리 로그의 로그 위치 "805"로 식별했습니다.
2
일요일 밤에 수행된 전체 복원 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
3
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
현재 바이너리 로그에서 PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
위치 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 위치를, mysqlbinlog를 사용하여 식별된 위치 에 있는 "804"로 설정하십시오. 중지 위치가 포함된 바이너리 로그다른 파일로 설정하고 텍스트 상자에 대상 바이너리 파일 이름(예: "MYSQLSVR-bin.000009")을 입력합니다.
방법 2: 오류 문 이전이후로 복원

DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 또한 DBA는 주문 테이블이 삭제된 시점 이후부터 현재의 바이너리 로그가 끝날 때까지 나머지 테이블에 발생한 트랜잭션을 복구하려고 합니다. 이러한 결정을 통해 삭제된 테이블을 복구하는 것 외에도 가능한 한 많은 트랜잭션을 복구할 수 있습니다. 또한 DBA는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 이 프로세스를 실행하려면 DBA가 일요일의 전체 백업을 복원하고 현재 바이너리 로그에서 PIT 복구를 수행해야 함을 의미합니다.

1
현재 바이너리 로그에 mysqlbinlog 유틸리티 사용: 이 단계는 NetVault Backup 외부에서 수행되어 DBA가 복원하지 않으려는 Drop Table 명령의 위치를 식별할 수 있습니다. (이 유틸리티 및 프로세스에 대한 자세한 내용은 MySQL 참조 안내서를 참조하십시오.) 이 프로세스에서 DBA는 Drop Table 명령을 "MYSQLSVR-PM-bin.000009" 바이너리 로그의 로그 위치 "805"로 식별했습니다.
2
일요일 밤에 수행된 전체 복원 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
3
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
현재 바이너리 로그에서 PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
위치 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 위치를, mysqlbinlog를 사용하여 식별된 위치 에 있는 "804"로 설정하십시오. 중지 위치가 포함된 바이너리 로그다른 파일로 설정하고 텍스트 상자에 대상 바이너리 파일 이름(예: "MYSQLSVR-PM-bin.000009")을 입력합니다.
오류/잘못된 SQL 문 이후로 복구 활성화: 이 옵션을 선택하고 시작 위치를, mysqlbinlog를 사용하여 식별된 위치 에 있는 "806"로 설정하십시오. 시작 위치가 포함된 바이너리 로그다른 파일로 설정하고 텍스트 상자에 대상 바이너리 파일 이름(예: "MYSQLSVR-bin.000009")을 입력합니다. 마지막으로, 명명된 바이너리 로그 마지막까지 복구를 수행하기 때문에 중지 위치에 대해 없음 옵션이 선택되었습니다.

전체 및 증분 백업 복원 시나리오

DBA는 매주 일요일 오후 11시전체 백업을, 월요일부터 토요일까지 오후 11시증분 백업을 수행하는 백업 정책을 설정했습니다. DBA는 증분 백업을 수행하고 있으므로 각 증분 백업 이후에 바이너리 로그가 삭제됩니다. 이 프로세스는 전체 백업의 속도를 향상시키지만 복원을 수행할 때는 더 많은 시간과 단계가 필요합니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 자신이 작업장에 도착하기 전인 목요일 오전 이른 시간에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 마지막 증분 백업, 즉 수요일 밤에 수행된 백업 시점으로의 전체 복구를 수행하기로 결정합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
수요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.

다음 예에서는 전체 백업 및 증분 백업 시나리오가 제시되며 DBA는 데이터를 특정 시점으로 복구하려고 합니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 수요일 오후 8시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 개발자가 테이블을 삭제한 수요일 오후 8시 직전 시점까지 데이터베이스를 복원하는 복구를 수행해야 합니다. 따라서 다음과 같은 단계를 수행합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
수요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: PIT 복구를 지정하고 모든 관련 옵션을 설정합니다.
바이너리 로그 복원 및 적용(시간 또는 위치를 이미 알고 있을 때 사용): 사용할 백업에 포함된 바이너리 로그를 지정합니다.
시간 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 날짜/시간"19:59""10 Jan 2007"로 설정합니다. 즉, 수요일 오후 8시의 1분 전입니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 수요일 오후 8시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 Drop Table 명령이 실행된 오후 8시 직전 시점으로 복구하기로 결정했습니다. 또한 DBA는 주문 테이블이 삭제된 이후 시점부터 백업 바이너리 로그 마지막까지 남아 있는 테이블에 발생한 트랜잭션도 복구하려고 합니다. 이러한 결정을 통해 삭제된 테이블을 복구하는 것 외에도 가능한 한 많은 트랜잭션을 복구할 수 있습니다. 따라서 다음과 같은 단계를 수행합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
수요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: PIT 복구를 지정하고 모든 관련 옵션을 설정합니다.
바이너리 로그 복원 및 적용(시간 또는 위치를 이미 알고 있을 때 사용): 사용할 백업에 포함된 바이너리 로그를 지정합니다.
시간 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 날짜/시간"19:59""10 Jan 2007"로 설정합니다. 즉, 수요일 오후 8시의 1분 전입니다.
오류/잘못된 SQL 문 이후로 복구 활성화: 주문 테이블이 삭제된 이후에 발생한 트랜잭션을 복구하도록 선택하고 이후 시간과 날짜를 시작 날짜/시간에 입력했습니다. 마지막으로, 백업에 포함된 바이너리 로그 마지막까지 복구를 수행하기 때문에 중지 날짜/시간에 대해 없음 옵션이 선택되었습니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 목요일 오전 6시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 개발자가 테이블을 삭제한 목요일 오전 6시 직전 시점까지 데이터베이스를 복원하는 복구를 수행해야 합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
수요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: PIT 복구를 지정하고 모든 관련 옵션을 설정합니다.
바이너리 로그 복원 및 적용(시간 또는 위치를 이미 알고 있을 때 사용): 사용할 백업에 포함된 바이너리 로그를 지정하도록 선택합니다.
현재 바이너리 로그 포함: 이 옵션을 선택하면 현재 바이너리 로그를 사용하여 수요일의 백업 완료 시간과 Drop Table 명령이 실행된 시간 사이에 발생한 항목을 적용할 수 있습니다.
시간 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 날짜/시간"5:59""11 Jan 2007"로 설정합니다. 즉, 목요일 오전 6시의 1분 전입니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 목요일 오전 6시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 또한 DBA는 주문 테이블이 삭제된 시점 이후부터 현재의 바이너리 로그가 끝날 때까지 나머지 테이블에 발생한 트랜잭션을 복구하려고 합니다. 이러한 결정을 통해 삭제된 테이블을 복구하는 것 외에도 가능한 한 많은 트랜잭션을 복구할 수 있습니다. 따라서 다음과 같은 단계를 수행합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
수요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: PIT 복구를 지정하고 모든 관련 옵션을 설정합니다.
바이너리 로그 복원 및 적용(시간 또는 위치를 이미 알고 있을 때 사용): 사용할 백업에 포함된 바이너리 로그를 지정하도록 선택합니다.
현재 바이너리 로그 포함: 이 옵션을 선택하면 현재 바이너리 로그를 사용하여 수요일의 백업 완료 시간과 Drop Table 명령이 실행된 시간 사이에 발생한 항목을 적용할 수 있습니다.
시간 기반 PIT: 유형으로 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 날짜/시간"5:59""11 Jan 2007"로 설정합니다. 즉, 목요일 오전 6시의 1분 전입니다.
오류/잘못된 SQL 문 이후로 복구 활성화: 주문 테이블이 삭제된 이후에 발생한 트랜잭션을 복구하도록 선택하고 이후 시간과 날짜를 시작 날짜/시간에 입력했습니다. 마지막으로, 현재 바이너리 로그 마지막까지 복구를 수행하기 때문에 중지 날짜/시간에 대해 없음 옵션이 선택되었습니다.

다음 예에서는 전체 백업 및 증분 백업 시나리오가 제시되며 DBA는 데이터를 특정 시점으로 복구하려고 합니다. 하지만 보다 명확한 방법으로 시간을 정의해야 합니다. 이 복구는 MySQL 바이너리 로그에 존재하는 식별된 "위치 값"을 사용하여 수행됩니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 수요일 오후 8시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 또한 DBA는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 이 프로세스를 수행하려면 DBA가 일요일의 전체 백업을 복원해야 하고, 이어서 월요일과 화요일에 수행된 증분 백업을 실시한 다음, 수요일 증분 백업을 사용하여 위치 기반 PIT 복구를 수행해야 합니다. 다음 단계에서는 이 프로세스를 설명합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.

이 단계에서는 수요일 밤의 증분 백업에 기록된 바이너리 로그만 임시 위치에 복원됩니다. 이 프로세스를 통해 DBA는 주문 테이블이 삭제된 시점을 표시하는 로그의 특정 위치를 찾을 수 있습니다.

1
수요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
시간 또는 위치를 식별하기 위해 로그를 임시 디렉터리로 복원: 수요일 밤의 증분 백업에 포함된 바이너리 로그만 복원하도록 선택합니다.
시간 기반 PIT: 유형으로 선택했지만 시간 기반 PIT 세부 정보 섹션에 있는 모든 옵션이 삭제되었습니다.

복원된 바이너리 로그에 mysqlbinlog 유틸리티 사용: 이 단계는 NetVault Backup 외부에서 수행되어 DBA가 복원하지 않으려는 Drop Table 명령의 위치를 식별할 수 있습니다. (이 유틸리티 및 프로세스에 대한 자세한 내용은 MySQL 참조 안내서를 참조하십시오.) 이 프로세스에서 DBA는 MySQL Server의 임시 위치로 복원된 "MYSQLSVR-bin.000009" 바이너리 로그의 로그 위치 "805"로 Drop Table 명령을 식별했으며 두 값이 모두 기록되었습니다.

복원된 바이너리 로그에서 위치를 식별하고 수요일의 증분 백업을 사용하여 PIT 복원을 수행합니다.

1
수요일 밤에 수행된 증분 백업 선택: DBA가 복원 작업 생성 - 저장 집합 선택 페이지 페이지에서 수요일의 증분 백업에 해당하는 백업 저장 집합을 다시 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
임시 디렉터리의 바이너리 로그 적용: 이 절차의 마지막 단계에서 임시 위치로 복원된 바이너리 로그를 대상으로 하도록 선택합니다. 복원된 바이너리 로그를 사용하여 Drop Table 명령이 사용된 특정 위치를 식별했기 때문에 플러그인에 동일한 바이너리 로그를 사용하도록 지시하기 위해 이 옵션을 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 위치를, mysqlbinlog를 사용하여 식별된 Drop Table 명령 위치 에 있는 바이너리 로그의 위치인 "804"로 설정하십시오. 중지 위치가 포함된 바이너리 로그 옵션은 임시 디렉터리에 복원된 바이너리 로그, "MYSQLSVR-bin.000009"를 선택하는 데 사용되었습니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 수요일 오후 8시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 또한 DBA는 주문 테이블이 삭제된 시점 이후부터 백업 바이너리 로그가 끝날 때까지 나머지 테이블에 발생한 트랜잭션을 복구하려고 합니다. 또한 DBA는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 이 프로세스를 수행하려면 DBA가 일요일의 전체 백업을 복원해야 하고, 이어서 월요일과 화요일에 수행된 증분 백업을 실시한 다음, 수요일 증분 백업을 사용하여 위치 기반 PIT 복구를 수행해야 합니다. 다음 단계에서는 이 프로세스를 설명합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.

이 단계에서는 수요일 밤의 증분 백업에 기록된 바이너리 로그만 임시 위치에 복원됩니다. 이 단계를 통해 DBA는 주문 테이블이 삭제된 시점을 표시하는 로그의 특정 위치를 찾을 수 있습니다.

1
수요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
시간 또는 위치를 식별하기 위해 로그를 임시 디렉터리로 복원: 수요일 밤의 증분 백업에 포함된 바이너리 로그만 복원하도록 선택합니다.
시간 기반 PIT: 유형으로 선택했지만 시간 기반 PIT 세부 정보 섹션에 있는 모든 옵션이 삭제되었습니다.

복원된 바이너리 로그에 mysqlbinlog 유틸리티 사용: 이 단계는 NetVault Backup 외부에서 수행되어 DBA가 복원하지 않으려는 Drop Table 명령의 위치를 식별할 수 있습니다. (이 유틸리티 및 프로세스에 대한 자세한 내용은 MySQL 참조 안내서를 참조하십시오.) 이 프로세스에서 DBA는 MySQL Server의 임시 위치로 복원된 "MYSQLSVR-bin.000009" 바이너리 로그의 로그 위치 "805"로 Drop Table 명령을 식별했으며 두 값이 모두 기록되었습니다.

복원된 바이너리 로그에서 위치를 식별하고 수요일의 증분 백업을 사용하여 PIT 복원을 수행합니다.

1
수요일 밤에 수행된 증분 백업 선택: DBA가 복원 작업 생성 - 저장 집합 선택 페이지 페이지에서 수요일의 증분 백업에 해당하는 백업 저장 집합을 다시 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
임시 디렉터리의 바이너리 로그 적용: 이 절차의 마지막 단계에서 임시 위치로 복원된 바이너리 로그를 대상으로 하도록 선택합니다. 복원된 바이너리 로그를 사용하여 Drop Table 명령이 사용된 특정 위치를 식별했기 때문에 플러그인에 동일한 바이너리 로그를 사용하도록 지시하기 위해 이 옵션을 선택합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고 중지 위치를, mysqlbinlog를 사용하여 식별된 Drop Table 명령 위치 에 있는 바이너리 로그의 위치인 "804"로 설정하십시오. 중지 위치가 포함된 바이너리 로그 옵션은 임시 디렉터리에 복원된 바이너리 로그, "MYSQLSVR-bin.000009"를 선택하는 데 사용되었습니다.
오류/잘못된 SQL 문 이후로 복구 활성화: 이 옵션을 선택하고 시작 위치를, mysqlbinlog를 사용하여 식별된 Drop Table 명령 위치 에 있는 바이너리 로그의 위치인 "806"으로 설정하십시오. 중지 위치가 포함된 바이너리 로그 옵션은 임시 디렉터리에 복원된 바이너리 로그, "MYSQLSVR-bin.000009"를 선택하는 데 사용되었습니다. 마지막으로, 명명된 바이너리 로그 마지막까지 복구를 수행하기 때문에 중지 날짜/시간에 대해 없음 옵션이 선택되었습니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 목요일 오전 6시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 개발자가 테이블을 삭제한 목요일 오전 6시 직전 시점까지 데이터베이스를 복원하는 복구를 수행해야 합니다. 또한 DBA는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 이 프로세스를 수행하려면 DBA가 일요일의 전체 백업을 복원해야 하고, 이어서 월요일과 화요일에 수행된 증분 백업을 실시한 다음, 수요일 증분 백업을 사용하여 위치 기반 PIT 복구를 수행해야 합니다. 다음 단계에서는 이 프로세스를 설명합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.

현재 바이너리 로그에 mysqlbinlog 유틸리티 사용: 이 단계는 NetVault Backup 외부에서 수행되어 DBA가 복원하지 않으려는 Drop Table 명령의 위치를 식별할 수 있습니다. (이 유틸리티 및 프로세스에 대한 자세한 내용은 MySQL 참조 안내서를 참조하십시오.) 이 프로세스에서 DBA는 Drop Table 명령을 현재 바이너리 로그 "MYSQLSVR-bin.000009"의 로그 위치 "805"로 식별했습니다.

복원된 바이너리 로그에서 위치를 식별하고 수요일의 증분 백업을 사용하여 PIT 복원을 수행합니다.

1
수요일 밤에 수행된 증분 백업 선택: DBA가 복원 작업 생성 - 저장 집합 선택 페이지 페이지에서 수요일의 증분 백업에 해당하는 백업 저장 집합을 다시 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
바이너리 로그 복원 및 적용(시간 또는 위치를 이미 알고 있을 때 사용): 백업에 포함된 바이너리 로그를 사용하도록 플러그인에 지시하기 위해 선택합니다.
현재 바이너리 로그 포함: 현재 바이너리 로그를 사용하여 수요일 밤의 증분 백업 이후에 발생한 모든 데이터베이스 트랙잭션을 적용하도록 NetVault Backup에 지시하기 위해 선택합니다. 이 단계는 수요일 밤의 증분 백업 완료 시간과 Drop Table 명령이 실행된 시간 사이에 발생한 모든 트랜잭션을 복구합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고, 중지 위치를, mysqlbinlog를 사용하여 식별된 Drop Table 명령 위치 에 있는 현재 바이너리 로그의 위치인 "804"로 설정하십시오. 중지 위치가 포함된 바이너리 로그다른 파일로 설정하고 텍스트 상자에 현재 바이너리 파일 이름(예: "MYSQLSVR-bin.000009")을 입력합니다.

DBA는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 목요일 오전 6시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

DBA는 개발자가 테이블을 삭제한 목요일 오전 6시 직전 시점까지 데이터베이스를 복원하는 복구를 수행해야 합니다. 또한 DBA는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 이 프로세스를 수행하려면 DBA가 일요일의 전체 백업을 복원해야 하고, 이어서 월요일과 화요일에 수행된 증분 백업을 실시한 다음, 수요일 증분 백업을 사용하여 위치 기반 PIT 복구를 수행해야 합니다. 다음 단계에서는 이 프로세스를 설명합니다.

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
월요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 월요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
화요일 밤에 수행된 증분 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 화요일의 증분 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.

현재 바이너리 로그에 mysqlbinlog 유틸리티 사용: 이 단계는 NetVault Backup 외부에서 수행되어 DBA가 복원하지 않으려는 Drop Table 명령의 위치를 식별할 수 있습니다. (이 유틸리티 및 프로세스에 대한 자세한 내용은 MySQL 참조 안내서를 참조하십시오.) 이 프로세스에서 DBA는 Drop Table 명령을 현재 바이너리 로그 "MYSQLSVR-bin.000009"의 로그 위치 "805"로 식별했습니다.

복원된 바이너리 로그에서 위치를 식별하고 수요일의 증분 백업을 사용하여 PIT 복원을 수행합니다.

1
수요일 밤에 수행된 증분 백업 선택: DBA가 복원 작업 생성 - 저장 집합 선택 페이지 페이지에서 수요일의 증분 백업에 해당하는 백업 저장 집합을 다시 선택합니다.
2
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다.
PIT 복구 수행: 이 형태의 복원 및 모든 관련 옵션을 사용하도록 선택합니다.
바이너리 로그 복원 및 적용(시간 또는 위치를 이미 알고 있을 때 사용): 백업에 포함된 바이너리 로그를 사용하도록 플러그인에 지시하기 위해 선택합니다.
현재 바이너리 로그 포함: 현재 바이너리 로그를 사용하여 수요일 밤의 증분 백업 이후에 발생한 모든 데이터베이스 트랙잭션을 적용하도록 NetVault Backup에 지시하기 위해 선택합니다. 이 단계는 수요일 밤의 증분 백업 완료 시간과 Drop Table 명령이 실행된 시간 사이에 발생한 모든 트랜잭션을 복구합니다.
오류/잘못된 SQL 문 이전으로 복구 활성화: 이 옵션을 선택하고, 중지 위치를, mysqlbinlog를 사용하여 식별된 Drop Table 명령 위치 에 있는 현재 바이너리 로그의 위치인 "804"로 설정하십시오. 중지 위치가 포함된 바이너리 로그다른 파일로 설정하고 텍스트 상자에 현재 바이너리 파일 이름(예: "MYSQLSVR-bin.000009")을 입력합니다.
오류/잘못된 SQL 문 이후로 복구 활성화: 이 옵션을 선택하고, 시작 위치를, mysqlbinlog를 사용하여 식별된 Drop Table 명령 위치 에 있는 현재 바이너리 로그의 위치인 "806"으로 설정하십시오. 중지 위치가 포함된 바이너리 로그다른 파일로 설정하고 텍스트 상자에 현재 바이너리 파일 이름(예: "MYSQLSVR-bin.000009")을 입력합니다. 마지막으로, 현재 바이너리 로그 마지막까지 복구를 수행하기 때문에 중지 위치에 대해 없음 옵션이 선택되었습니다.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating