전체 및 차등 백업 복원 시나리오
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는 목요일 오전 9시에 주문 테이블에 "테이블을 찾을 수 없음" 오류가 발생한 사실을 확인했습니다. 그런 다음 DBA는 수요일 오후 8시에 개발자가 실수로 테이블을 삭제하여 해당 테이블이 더 이상 존재하지 않는다는 것을 알게 됩니다.
DBA는 Drop Table 명령이 실행되기 직전의 시점까지 복구하기로 결정합니다. 또한 DBA는 보다 정확한 복원을 원하므로 위치 기반 복구를 사용하기로 결정했습니다. 다음 단계에서는 이 프로세스를 설명합니다.
|
1 |
일요일 밤에 수행된 전체 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 일요일의 전체 백업에 해당하는 백업 저장 집합을 선택합니다. |
|
2 |
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다. |
|
1 |
수요일 밤에 수행된 차등 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 차등 백업에 해당하는 백업 저장 집합을 선택합니다. |
|
2 |
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다. |
|
• |
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 |
모든 복원 관련 옵션을 기본값으로 유지: 이러한 옵션 중 어떤 것도 사용되지 않습니다. |
|
1 |
수요일 밤에 수행된 차등 백업 선택: 복원 작업 생성 - 저장 집합 선택 페이지에서 DBA는 수요일의 차등 백업에 해당하는 백업 저장 집합을 선택합니다. |
|
2 |
복원 관련 옵션 탭에서 특정 옵션 설정: DBA가 다음 옵션을 설정합니다. |
|
• |
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 바이너리 로깅 형식을 사용하며 모든 데이터베이스 사용자와 프로그램이 수정된 테이블이 USE에서 선택된 데이터베이스에 있고, 데이터베이스 간 업데이트가 실행되지 않도록 하는 최상의 방법을 따르는 경우 이 항목은 사용자 사이트에 적용되지 않습니다. (자세한 내용은 MIXED 바이너리 로깅 형식 사용을 참조하십시오.) PIT 복원 작업을 실행할 수 있으며, 작업 중 선택한 데이터베이스의 지정된 지점으로 바이너리 로그를 재생할 수 있습니다. |
이전에 설명한 대로, 사용자 환경의 사용자와 프로그램이 USE에서 선택되지 않은 데이터베이스의 테이블을 수정하고 데이터베이스 간 업데이트를 실행하면 PIT 복원 작업을 실행할 때 트랜잭션이 지정된 시점으로 재생되지 않을 수 있습니다. 그러므로 Quest의 권장 사항에 따라 모든 데이터베이스 사용자와 프로그램에서 수정된 테이블이 USE에서 선택된 데이터베이스에 있도록 합니다. 또한 데이터베이스 간 업데이트가 실행되지 않도록 하는 것이 좋습니다. 이 지침이 사용자 환경에 적합하지 않을 경우 Quest에서는 MIXED 바이너리 로깅 형식을 사용하지 않도록 권장합니다.
|
중요: 다음 절차에서는 "--database" 옵션 없이 mysqlbinlog를 사용합니다. 따라서 바이너리 로그의 모든 내용을 적용하고 모든 데이터베이스를 수정할 수 있습니다. 대체 MySQL Server에 이 절차를 적용하고 대체 MySQL Server에서 해당 데이터를 추출해 보십시오. 프로덕션 MySQL Server에 다음 절차를 적용할 경우 모든 데이터베이스가 지정된 지점으로 롤백됩니다. 모든 MySQL Server 데이터베이스를 지정된 지점으로 롤백하려는 경우를 제외하고 프로덕션 환경에 이 절차를 적용하지 마십시오. |
|
1 |
탐색 창에서 복원 작업 생성을 클릭합니다. |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
mysqlbinlog 명령 프롬프트에서 바이너리 로그를 수동으로 적용하려면 다음을 입력합니다. |
MySQL Enterprise Backup 복원 시나리오 예시
실패 또는 데이터 손상에서 복구하려면 복원을 위해 선택한 데이터 및 옵션 탭에서 사용 가능한 옵션과 관련하여 작업을 설정할 때 다양한 설정을 수행해야 합니다.
전체 백업 전용 복원 시나리오
|
1 |
|
2 |