9.3 Example Backup and Recovery Strategy

9.3 Example Backup and Recovery Strategy

이 절에서는 여러 유형의 장애 이후에 데이터를 복구할 수 있게 해 주는 backup 수행 절차에 대해 설명합니다:

• Operating system crash

• Power failure

• File system crash

• Hardware problem (hard drive, motherboard, and so forth)

예제 명령에는 mysqldump 및 mysql 클라이언트 프로그램에 대한 --user 및 --password와 같은 옵션이 포함되어 있지 않습니다. 이러한 옵션은 클라이언트 프로그램이 MySQL 서버에 연결할 수 있도록 필요한 경우 포함해야 합니다.

데이터가 트랜잭션 및 자동 크래시 복구를 지원하는 InnoDB 스토리지 엔진에 저장되어 있다고 가정합니다. 또한 크래시 시점에 MySQL 서버에 부하가 걸려 있다고 가정합니다. 그렇지 않다면 어떤 복구도 필요하지 않을 것입니다.

Operating system crash 또는 power failure의 경우, 재시작 후 MySQL의 디스크 데이터는 사용 가능하다고 가정할 수 있습니다. InnoDB 데이터 파일은 크래시로 인해 일관된 데이터를 포함하지 않을 수 있지만, InnoDB는 로그를 읽고 그 안에서 데이터 파일에 플러시되지 않은 보류 상태의 커밋된 및 커밋되지 않은 트랜잭션 목록을 찾습니다.

InnoDB는 커밋되지 않은 트랜잭션을 자동으로 롤백하고, 커밋된 트랜잭션은 데이터 파일로 플러시합니다. 이 복구 프로세스에 대한 정보는 MySQL 에러 로그를 통해 사용자에게 전달됩니다. 다음은 로그 발췌 예시입니다:

1InnoDB: Database was not shut down normally.
2InnoDB: Starting recovery from log files...
3InnoDB: Starting log scan based on checkpoint at
4InnoDB: log sequence number 0 13674004
5InnoDB: Doing recovery: scanned up to log sequence number 0 13739520
6InnoDB: Doing recovery: scanned up to log sequence number 0 13805056
7InnoDB: Doing recovery: scanned up to log sequence number 0 13870592
8InnoDB: Doing recovery: scanned up to log sequence number 0 13936128
9...
10InnoDB: Doing recovery: scanned up to log sequence number 0 20555264
11InnoDB: Doing recovery: scanned up to log sequence number 0 20620800
12InnoDB: Doing recovery: scanned up to log sequence number 0 20664692
13InnoDB: 1 uncommitted transaction(s) which must be rolled back
14InnoDB: Starting rollback of uncommitted transactions
15InnoDB: Rolling back trx no 16745
16InnoDB: Rolling back of trx no 16745 completed
17InnoDB: Rollback of uncommitted transactions completed
18InnoDB: Starting an apply batch of log records to the database...
19InnoDB: Apply batch completed
20InnoDB: Started
21mysqld: ready for connections

File system crash 또는 hardware problem의 경우, 재시작 후 MySQL 디스크 데이터가 사용 불가능하다고 가정할 수 있습니다. 이는 일부 디스크 데이터 블록을 더 이상 읽을 수 없기 때문에 MySQL이 정상적으로 시작되지 못함을 의미합니다.

이 경우 디스크를 다시 포맷하거나, 새 디스크를 설치하거나, 기타 방식으로 근본적인 문제를 수정해야 합니다. 그런 다음 backup에서 MySQL 데이터를 복구해야 하며, 이는 이미 backup이 생성되어 있어야 함을 의미합니다. 이를 보장하기 위해 backup 정책을 설계하고 구현해야 합니다.