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

직업 마무리 및 제출

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

중요: 대상 OS의 파일 이름에 지원되지 않는 특수 문자를 사용하지 마십시오. 예를 들어 /,\,*, @ 문자는 Windows에서 사용할 수 없습니다. 이 요구 사항은 MySQL용 플러그인‑이 데이터를 임시로 복원하기 위해 작업 제목과 동일한 이름의 폴더를 생성하려고 하기 때문입니다.

팁: 선택을 클릭한 다음 대상 클라이언트 선택 대화 상자에서 해당 클라이언트를 찾아 선택합니다.

중요: 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시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.

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

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

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

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

중요: 중지 및 시작 위치는 원치 않는 트랜잭션의 위치보다 큰 임의의 숫자가 아니라 바이너리 로그에 나열된 실제 위치여야 합니다.

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

중요: 중지 및 시작 위치는 원치 않는 트랜잭션의 위치보다 큰 임의의 숫자가 아니라 바이너리 로그에 나열된 실제 위치여야 합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

중요: 중지 및 시작 위치는 원치 않는 트랜잭션의 위치보다 큰 임의의 숫자가 아니라 바이너리 로그에 나열된 실제 위치여야 합니다.

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

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

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

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

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

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

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

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

중요: 중지 및 시작 위치는 원치 않는 트랜잭션의 위치보다 큰 임의의 숫자가 아니라 바이너리 로그에 나열된 실제 위치여야 합니다.