Tchater maintenant avec le support
Tchattez avec un ingénieur du support

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

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

전체 및 차등 백업 복원 시나리오

DBA는 매주 일요일 오후 11시전체 백업을, 월요일부터 토요일까지 오후 11시차등 백업을 수행하는 백업 정책을 설정했습니다. DBA가 차등 백업을 수행하고 있으므로 각 차등 백업 이후에 바이너리 로그가 유지되므로 백업 시간은 더 길어지지만 전반적으로 복원 속도가 빨라집니다.

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

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

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
수요일 밤에 수행된 차등 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 차등 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 옵션 탭에서 사용할 수 있는 옵션이 사용되지 않습니다.
중요: DBA가 월요일화요일 밤의 차등 백업을 복원하지 않아도 됩니다. 차등 백업을 수행하도록 선택하면 매일 밤의 백업이 누적되어 일요일 밤의 전체 백업으로 돌아갑니다. 즉, 수요일 밤의 백업에는 월요일, 화요일 그리고 수요일에 생성된 모든 바이너리 로그가 포함되어 일요일의 전체 백업으로 돌아갑니다.

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

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

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

1
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다.
2
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다.
1
수요일 밤에 수행된 차등 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 차등 백업에 해당하는 백업 저장 집합을 선택합니다.
중요: 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는 수요일의 차등 백업에 해당하는 백업 저장 집합을 선택합니다.
중요: 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는 수요일의 차등 백업에 해당하는 백업 저장 집합을 선택합니다.
중요: 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는 수요일의 차등 백업에 해당하는 백업 저장 집합을 선택합니다.
중요: 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는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 다음 단계에서는 이 프로세스를 설명합니다.

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

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

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

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가 복원 작업 생성 - 저장 집합 선택 페이지 페이지에서 수요일의 차등 백업에 해당하는 백업 저장 집합을 다시 선택합니다.
중요: 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는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 다음 단계에서는 이 프로세스를 설명합니다.

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

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

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

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

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

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

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

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

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

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

MIXED 바이너리 로깅 형식이 사용되고 데이터베이스 간 업데이트가 실행되는 경우의 PIT 복원

MIXED 바이너리 로깅 형식이 사용되고 데이터베이스 간 업데이트가 실행되는 경우의 PIT 복원
중요: 사용자 사이트에서 MIXED 바이너리 로깅 형식을 사용하며 모든 데이터베이스 사용자와 프로그램이 수정된 테이블이 USE에서 선택된 데이터베이스에 있고, 데이터베이스 간 업데이트가 실행되지 않도록 하는 최상의 방법을 따르는 경우 이 항목은 사용자 사이트에 적용되지 않습니다. (자세한 내용은 MIXED 바이너리 로깅 형식 사용을 참조하십시오.) PIT 복원 작업을 실행할 수 있으며, 작업 중 선택한 데이터베이스의 지정된 지점으로 바이너리 로그를 재생할 수 있습니다.

이전에 설명한 대로, 사용자 환경의 사용자와 프로그램이 USE에서 선택되지 않은 데이터베이스의 테이블을 수정하고 데이터베이스 간 업데이트를 실행하면 PIT 복원 작업을 실행할 때 트랜잭션이 지정된 시점으로 재생되지 않을 수 있습니다. Quest의 권장 사항에 따라 모든 데이터베이스 사용자와 프로그램에서 수정된 테이블이 USE에서 선택된 데이터베이스에 있도록 합니다. 또한 데이터베이스 간 업데이트가 실행되지 않도록 하는 것이 좋습니다. 이 지침이 사용자 환경에 적합하지 않을 경우 Quest에서는 MIXED 바이너리 로깅 형식을 사용하지 않도록 권장합니다.

중요: 다음 절차에서는 "--database" 옵션 없이 mysqlbinlog를 사용합니다. 따라서 바이너리 로그의 모든 내용을 적용하고 모든 데이터베이스를 수정할 수 있습니다. 대체 MySQL Server에 이 절차를 적용하고 대체 MySQL Server에서 해당 데이터를 추출해 보십시오. 프로덕션 MySQL Server에 다음 절차를 적용할 경우 모든 데이터베이스가 지정된 지점으로 롤백됩니다. 모든 MySQL Server 데이터베이스를 지정된 지점으로 롤백하려는 경우를 제외하고 프로덕션 환경에 이 절차를 적용하지 마십시오.
1
탐색 창에서 복원 작업 생성을 클릭합니다.
2
복원 작업 생성 - 저장 집합 선택 페이지에서 테이블 필터링을 클릭하고 필터 편집을 선택합니다.
3
플러그인 유형 목록에서 MySQL용 플러그인‑을 선택합니다.
5
선택 집합 만들기 페이지에서 바이너리 로그를 선택합니다.
6
선택 집합 만들기 페이지에서 플러그인 옵션 편집을 클릭합니다.
7
특정 시점 복구 탭에서 PIT 복구 수행시간 또는 위치를 식별하기 위해 로그를 임시 디렉터리로 복원 옵션을 선택합니다.
바이너리 로그는 다음 위치에 있는 임시 디렉터리에 복원됩니다. <NetVaultBackupInstallationDirectory>/tmp/mysql/<savesetName>
8
mysqlbinlog 명령 프롬프트에서 바이너리 로그를 수동으로 적용하려면 다음을 입력합니다.
"<NetVaultBackupInstallationDirectory>/tmp/mysql/<savesetName>" |
서로 다른 증분 백업 저장 집합은 <NetVaultBackupInstallationDirectory>/tmp/mysql 디렉터리의 다른 하위 디렉터리에 복원됩니다. 그런 다음 각 디렉터리에 mysqlbinlog 명령을 적용하거나 모든 바이너리 로그를 일반 디렉터리로 복사하거나 이동하여 mysqlbinlog를 실행할 수 있습니다.

MySQL Enterprise Backup 복원 시나리오 예시

실패 또는 데이터 손상에서 복구하려면 복원을 위해 선택한 데이터 및 옵션 탭에서 사용 가능한 옵션과 관련하여 작업을 설정할 때 다양한 설정을 수행해야 합니다.

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

1
복원할 준비가 완료된 전체 백업을 생성하려면 옵션 탭에서 복원, 원시 전체 백업 추출... 옵션을 선택한 작업을 제출합니다.
2
MySQL을 종료하고 MySQL Server 리포지토리에 준비된 전체 백업을 복사하려면 옵션 탭에서 MySQL Server 종료 및 다시 복사… 옵션을 선택한 작업을 제출합니다.
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation