MySQL5.6 바이너리 로그를 사용한 시점 (증분) 복구

7.5 바이너리 로그를 사용한 시점 (증분) 복구

7.5.1 이벤트 시간을 사용한 시점 복구
7.5.2 이벤트의 위치를 사용한 시점 복구

시점 복구는 특정 시점 이후의 데이터 변경의 복구를 나타냅니다. 일반적으로이 종류의 복구 서버를 백업이 수행 된 시점의 상태로 전체 백업 복원 후에 실행됩니다. (전체 백업은 7.2 절 "데이터베이스 백업 방법" 에 설명 된 것과 같은 여러 가지 방법으로 할 수 있습니다.) 또한 시점 복구는 전체 백업의 시점부터 더 최근 시점까지 점진적으로 서버를 최신으로합니다.

시점 복구는 이러한 원칙에 근거합니다.

시점 복구 정보의 소스는 전체 백업 작업 후에 생성 된 바이너리 로그 파일에 의해 나타내지는 일련의 증분 백업입니다. 따라서 서버를 --log-bin 옵션으로 시작하여 바이너리 로깅을 활성화해야합니다 ( 섹션 5.2.4 "바이너리 로그" 를 참조하십시오).

바이너리 로그에서 데이터를 복원하려면 현재 바이너리 로그 파일의 이름과 위치를 알고 있어야합니다. 기본적으로 서버는 데이터 디렉토리에 바이너리 로그 파일을 만들지 만, --log-bin 옵션에서 경로 이름을 지정하여 다른 위치에 파일을 넣을 수 있습니다. 섹션 5.2.4 "바이너리 로그" .

모든 바이너리 로그 파일의 목록을 표시하려면 다음 문을 사용합니다.
```
 mysql> SHOW BINARY LOGS;
```
현재 바이너리 로그 파일의 이름을 확인하려면 다음 문을 실행합니다.
```
 mysql> SHOW MASTER STATUS;
```
mysqlbinlog 유틸리티는 바이너리 로그 파일의 이벤트를 실행하거나 표시 할 수 있도록 바이너리 형식에서 텍스트로 변환합니다. mysqlbinlog에는 이벤트 시간과 로그의 이벤트의 위치에 따라 바이너리 로그의 섹션을 선택하는 옵션이 있습니다. 섹션 4.6.8 "mysqlbinlog - 바이너리 로그 파일을 처리하기위한 유틸리티" 를 참조하십시오.
바이너리 로그에서 이벤트를 실행하면 그것들이 나타내는 데이터의 변경이 다시 실행됩니다. 이렇게하면 특정 기간의 데이터 변경의 복구가 가능합니다. 바이너리 로그에서 이벤트를 실행하려면 mysql 클라이언트를 사용하여 mysqlbinlog 출력을 처리합니다.
```
 shell> mysqlbinlog binlog_files | mysql -u root -p
```
로그의 내용을 표시하면 이벤트를 실행하기 전에 이벤트의 시간과 위치를 특정하여 로그 내용의 일부를 선택해야하는 경우에 유용 할 수 있습니다. 로그에서 이벤트를 표시하려면 mysqlbinlog 출력을 페이징 프로그램에 보냅니다.
```
 shell> mysqlbinlog binlog_files | more
```
또는 출력을 파일에 저장하고 텍스트 편집기에서 파일을 표시합니다.
```
 shell> mysqlbinlog binlog_files > tmpfile
 shell> ... edit tmpfile ...
```
파일에 출력을 저장하는 것은 예기치 않은 DROP DATABASE 등 특정 이벤트가 삭제 된 로그의 내용을 실행하는 경우 예비로 도움이됩니다. 파일의 내용을 실행하기 전에 실행되지 않는 문을 파일에서 삭제할 수 있습니다. 파일을 편집 한 후 다음과 같이 내용을 실행합니다.
```
 shell> mysql -u root -p < tmpfile
```

MySQL 서버에 실행하는 여러 바이너리 로그가있는 경우 안전한 방법은 서버에 하나의 연결을 사용하여 그들 모두를 처리하는 것입니다. 이것은 안전하지 않을 수 있음을 보여주는 예입니다.

 shell> mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
 shell> mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!

첫 번째 로그 파일에 CREATE TEMPORARY TABLE 문이 포함되어 있으며, 두 번째 로그에 임시 테이블을 사용하는 명령문이 포함되어있는 경우 서버에 다른 연결을 사용하여 이러한 바이너리 로그를 처리 그러면 문제가 발생합니다. 첫 번째 mysql 프로세스가 종료하면 서버는 임시 테이블을 삭제합니다. 두 번째 mysql 프로세스에서 테이블의 사용을 시도하면 서버는 "알 수없는 테이블"고보고합니다.

이러한 문제를 해결하려면 하나의 연결을 사용하여 처리하는 모든 바이너리 로그의 내용을 실행합니다. 이것은 그것을 실행하는 하나의 방법입니다.

 shell> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p

또 다른 방법은 모든 로그를 하나의 파일에 기록한 다음 그 파일을 처리하는 것입니다.

 shell> mysqlbinlog binlog.000001 > /tmp/statements.sql
 shell> mysqlbinlog binlog.000002 >> /tmp/statements.sql
 shell> mysql -u root -p -e "source /tmp/statements.sql"

GTID ( 섹션 17.1.3 "글로벌 트랜잭션 식별자를 사용한 복제" 참조)을 포함한 바이너리 로그에서 읽기하면서 덤프 파일에 기록하는 경우 다음과 같이 mysqlbinlog에서 --skip-gtids 옵션을 사용합니다.

 shell> mysqlbinlog --skip-gtids binlog.000001 > /tmp/dump.sql
 shell> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
 shell> mysql -u root -p -e "source /tmp/dump.sql"