9.3.2 Using Backups for Recovery

9.3.2 Using Backups for Recovery

이제, 수요일 오전 8시에 재해 수준의 예상치 못한 종료가 발생하여 백업으로부터의 복구가 필요하다고 가정해 보겠습니다. 복구를 위해 먼저 우리가 가지고 있는 마지막 전체 백업(일요일 오후 1시의 것)을 복원합니다. 전체 백업 파일은 단순히 SQL 구문들의 집합이므로 복원 작업은 매우 쉽습니다:

1$> mysql < backup_sunday_1_PM.sql

이 시점에서 데이터는 일요일 오후 1시 시점의 상태로 복원됩니다. 그 이후에 이루어진 변경 사항을 복원하려면 증분 백업을 사용해야 합니다. 즉,
gbichot2-bin.000007 및
gbichot2-bin.000008 바이너리 로그 파일을 사용해야 합니다. 필요하다면 백업해 둔 위치에서 이 파일들을 가져온 후, 다음과 같이 그 내용을 처리합니다:

1$> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

이제 데이터는 화요일 오후 1시 시점의 상태로 복구되었지만, 그 시점부터 크래시가 발생한 시점까지의 변경 사항은 여전히 누락되어 있습니다. 이러한 변경 사항을 잃지 않으려면, MySQL 서버가 MySQL 바이너리 로그를 데이터 파일을 저장하는 위치와는 다른 안전한 위치(RAID 디스크, SAN, ...)에 저장하도록 했어야 합니다.

그렇게 해야 로그가 손상된 디스크에는 존재하지 않게 됩니다. (즉, 서버를 시작할 때 데이터 디렉터리가 존재하는 물리적 장치와는 다른 물리적 장치 상의 위치를 지정하는 --log-bin 옵션을 사용할 수 있습니다. 이렇게 하면, 해당 디렉터리를 포함한 장치를 잃더라도 로그는 안전하게 보호됩니다.) 만약 이렇게 설정해 두었다면,
gbichot2-bin.000009 파일(및 그 이후 파일들)을 손에 쥐고 있게 되었을 것이며, 이 파일들을 mysqlbinlog 및
mysql을 사용해 적용함으로써 크래시가 발생한 순간까지의 최신 데이터 변경 사항을 손실 없이 복원할 수 있었을 것입니다:

1$> mysqlbinlog gbichot2-bin.000009 ... | mysql

바이너리 로그 파일을 처리하기 위해 mysqlbinlog를 사용하는 방법에 대한 자세한 내용은
Section 9.5, “Point-in-Time (Incremental) Recovery”를 참조하십시오.