7.3.2 복구에 대한 백업 사용

여기서 수요일 오전 8시 백업에서 복구를 필요로하는 치명적인 충돌이 있었다고합니다. 복구하려면 먼저 존재하는 마지막 전체 백업 (일요일 오후 1시)를 복원합니다. 전체 백업 파일은 일련의 SQL 문에 지나지 않기 때문에 그 복원은 매우 간단합니다.

 shell> mysql < backup_sunday_1_PM.sql 

이 시점에서, 데이터는 일요일 오후 1시 현재의 상태로 복원됩니다. 이후에 변경된 내용을 복원하려면 증분 백업을 사용해야합니다. 즉, gbichot2-bin.000007 및 gbichot2-bin.000008 바이너리 로그 파일입니다. 필요한 경우 백업 된 위치에서 파일을 가져올하여 다음과 같이 그 내용을 처리합니다.

 shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

이제 데이터를 화요일 오후 1시 현재의 상태로 복구했지만 여전히 그 날부터 충돌 일까지 변경이 부족합니다. 그들을 잃지 않기 위해 MySQL 서버로 MySQL 바이너리 로그를 데이터 파일을 저장하는 곳과 다른 안전한 장소 (RAID 디스크, SAN 등)에 저장하고 이러한 로그가 손상된 디스크에 없도록해야했습니다. (즉, 데이터 디렉토리가있는 위치와 다른 물리적 장치의 위치를 지정하는 --log-bin 옵션으로 서버를 시작할 수 있습니다. 이렇게하면 디렉토리를 저장하는 장치가 손상 되더라도 로그 안전합니다.) 이렇게하지 않으면 gbichot2-bin.000009 파일 (및 모든 후속 파일)을 수중에 있기 때문에 mysqlbinlog 및 mysql을 사용하여 그들을 적용하고 충돌의 순간까지 손실 없이 최신의 데이터 변경을 복원 할 수 있습니다.

 shell> mysqlbinlog gbichot2-bin.000009 ... | mysql

mysqlbinlog를 사용하여 바이너리 로그 파일을 처리하는 자세한 내용은 섹션 7.5 "바이너리 로그를 사용한 시점 (증분) 복구" 를 참조하십시오.