14.16 InnoDB 백업 및 복구

안전한 데이터베이스 관리의 핵심은 정기적 인 백업을 만들 것입니다. 데이터 볼륨, MySQL 서버의 수 및 데이터베이스 워크로드에 따라 다음의 방법을 단독으로 또는 조합하여 사용할 수 있습니다. 즉, MySQL Enterprise Backup을 사용하여 핫 백업 , MySQL 서버 종료시에 파일을 복사하는 데 따른 콜드 백업 , 신속한 조작 (특히 복원)을위한 물리적 백업 작은 데이터 볼륨을 위해 또는 스키마 오브젝트의 구조 를 기록하는 mysqldump를 사용하여 논리적 백업 입니다.

핫 백업

MySQL Enterprise Backup 구성 요소의 일부인 mysqlbackup 명령을 사용하면 실행중인 MySQL 인스턴스 ( InnoDB 와 MyISAM 테이블을 포함)을 데이터베이스의 일관된 스냅 샷을 생성하면서 운영 중단을 최소화 억제하고 백업 할 수 있습니다. mysqlbackup이 InnoDB 테이블을 복사하는 동안, InnoDB 테이블과 MyISAM 테이블에 대해 읽기와 쓰기를 계속할 수 있습니다. MyISAM 테이블을 복사하는 동안 이러한 테이블에 대한 (쓰기가 아닌) 읽기가 허용됩니다. MySQL Enterprise Backup은 또한 압축 백업 파일을 만들거나 테이블이나 데이터베이스의 일부를 백업 할 수 있습니다. MySQL 바이너리 로그와 함께 사용하면 사용자는 시점 복구를 실행할 수 있습니다. MySQL Enterprise Backup은 MySQL Enterprise 구독의 일부입니다. 자세한 내용은 섹션 25.2 "MySQL Enterprise Backup" 을 참조하십시오.

콜드 백업

MySQL 서버를 종료 할 경우, InnoDB 가 테이블을 관리하는 데 사용하는 모든 파일로 구성된 바이너리 백업을 만들 수 있습니다. 다음 단계를 사용합니다.

대체 백업의 종류

지금 설명했다 바이너리 백업을 만들뿐만 아니라, mysqldump를 사용하여 테이블의 덤프를 정기적으로 작성합니다. 바이너리 파일은 사용자도 모르는 사이에 손상 될 수 있습니다. 덤프 된 테이블은 인간이 읽을 수있는 텍스트 파일에 저장되므로 테이블의 손상을 쉽게 찾을 수 있습니다. 또한 형식이 단순하기 때문에 심각한 데이터 손상이 발생할 가능성도 적습니다. mysqldump는 다른 클라이언트를 잠그지 않고도 일관성있는 스냅 샷을 만들기위한 --single-transaction 옵션도 준비되어 있습니다. 섹션 7.3.1 "백업 정책 설정" 을 참조하십시오.

복제은 InnoDB 테이블과 연계하여 작동하기 때문에 MySQL의 복제 기능을 사용하여 데이터베이스 복사본을 고 가용성이 필요한 데이터베이스 사이트에 저장할 수 있습니다.

복구 수행

InnoDB 데이터베이스를 바이너리 백업이 생성 된 시점부터 현재에 복구하려면 백업을 만들기 전에라도 바이너리 로깅을 선택하고 MySQL 서버를 실행해야합니다. 백업을 복원 한 후 시점 복구를 실현하려면 백업이 생성 된 이후에 발생한 변경을 바이너리 로그에서 적용 할 수 있습니다. 섹션 7.5 "바이너리 로그를 사용한 시점 (증분) 복구" 를 참조하십시오.

MySQL 서버의 오류를 복구 할 수있는 유일한 요구 사항은 서버를 다시 시작합니다. InnoDB 는 로그를 자동으로 확인하고 데이터베이스의 현재에 롤 포워드합니다. InnoDB 는 충돌 시점에 존재하고 있던 커밋되지 않은 트랜잭션을 자동으로 롤백합니다. 복구 중에 mysqld는 다음과 같은 출력을 표시합니다.

 InnoDB : Database was not shut down normally.
 InnoDB : Starting recovery from log files ...
 InnoDB : Starting log scan based on checkpoint at
 InnoDB : log sequence number 0 13674004
 InnoDB : Doing recovery : scanned up to log sequence number 0 13739520
 InnoDB : Doing recovery : scanned up to log sequence number 0 13805056
 InnoDB : Doing recovery : scanned up to log sequence number 0 13870592
 InnoDB : Doing recovery : scanned up to log sequence number 0 13936128
 ...
 InnoDB : Doing recovery : scanned up to log sequence number 0 20555264
 InnoDB : Doing recovery : scanned up to log sequence number 0 20620800
 InnoDB : Doing recovery : scanned up to log sequence number 0 20664692
 InnoDB : 1 uncommitted transaction (s) which must be rolled back
 InnoDB : Starting rollback of uncommitted transactions
 InnoDB : Rolling back trx no 16745
 InnoDB : Rolling back of trx no 16745 completed
 InnoDB : Rollback of uncommitted transactions completed
 InnoDB : Starting an apply batch of log records to the database ...
 InnoDB : Apply batch completed
 InnoDB : Started
 mysqld : ready for connections

데이터베이스가 손상되거나 디스크 장애가 발생하면 백업을 사용하여 복구를 수행해야합니다. 손상의 경우는 먼저 손상되지 않은 백업을 찾습니다. 기반 백업을 복원 한 뒤, mysqlbinlog 및 mysql을 사용하여 바이너리 로그 파일에서 특정 시점 복구를 실행하면 백업이 만들어진 후에 발생한 변경을 복원합니다.

데이터베이스 손상 정도에 따라 하나 이상의 손상된 테이블을 덤프하고 삭제하고 다시 작성하는 것만으로 충분한 경우가 있습니다. 테이블이 손상된 여부는 CHECK TABLE SQL 문을 사용하여 확인할 수 있습니다. 그러나 당연히 CHECK TABLE 이 수있는 모든 종류의 손상을 감지 할 수 없습니다. 테이블 스페이스 모니터를 사용하면 테이블 스페이스 파일 내부의 파일 공간 관리의 무결성을 확인할 수 있습니다.

경우에 따라 외형은 데이터베이스 페이지의 손상이지만, 실제로는 운영 체제에 의한 독자적인 파일 캐시의 손상이며, 디스크의 데이터는 정상임을 수 있습니다. 먼저 컴퓨터를 재시작 해 보는 것이 좋습니다. 이로 인해 데이터베이스 페이지의 손상 보였다 오류가 해결 될 수 있습니다. InnoDB 의 일관성 문제를 위해 MySQL을 계속 시작할 수없는 경우는 섹션 14.19.2 "InnoDB 복구 강제 실행" 을 참조하여 데이터를 덤프 할 진단 모드로 인스턴스를 시작하는 방법을 알아 하십시오.