원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어

출처 : 한국MySQL 한글매뉴얼 참조.(MySQL Replication 개요)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

mysql의 바이너리 로그의 목적

1. replication 동기화
2. 지난 쿼리의 저장
3. 데이터베이스 복구

1. Replication 동기화
MySQL은 단 방향, 즉 비동기 리플리케이션 (asynchronous replication)을 지원하는데, 하나의 서버는 마스터로 동작하고, 나머지 한 개 이상의 다른 서버들은 슬레이브로 동작한다. 이것은 MySQL클러스터의 특징인 동기화 (synchronous) 리플리케이션과는 반대되는 개념이다. ( Chapter 15, MySQL 클러스터)를 참조할 것.

싱글-마스터 리플리케이션에서, 마스터 서버는 업데이트를 자신의 바이너리 로그 파일에 작성하고 로그 로테이션의 트레이스 (trace)를 유지하기 위해 이 파일의 인덱스를 유지 관리 한다. 바이너리 로그 파일은 다른 슬레이브 서버에 전달되는 업데이트 레코드 역할을 한다. 슬레이브가 자신의 마스터에 연결이 될 때, 마스터 정보를 자신이 마지막으로 업데이트가 성공했을 때 읽었던 로그에 전달한다. 슬레이브는 그 시간 이후에 발생한 모든 사항에 대한 업데이트를 전달 받고, 블록 (block)을 한 후에 마스터가 새로운 업데이트를 알려 주기를 기다리게 된다.

2. 지난 쿼리의 저장

바이너리 로그는 디비에 업데이트가 일어나는 모든 쿼리가 시간과 함께 기록된다.
형식은 mysql/var/호스트이름-bin.넘버
이 넘버는 디비 재시작시마다 카운트가 올라간다.

* 업데이트가 일어날때마다 모든 쿼리가 저장되기 때문에 나중에 용량이 많이 늘어날수 있다.
* 서버 용량상 바이너리로그를 저장하지 않으려면 my.cnf에서 log-bin 부분을 제거하면 된다.

다음 명령어로 bin-log를 일반쿼리로 변경할 수 있다.

# mysqlbinlog /usr/local/mysql/var/host-bin.00003 > view.sql

3. 데이터베이스 복구에 이용

bin-log를 일반쿼리로 변경하여 백업에 이용할 수도 있다.

# mysqlbinlog /usr/local/mysql/var/host-bin.00003 > backup.sql

이를 이용해서 오라클 처럼 time-based recovery도 가능해진다.

# mysqlbinlog --start-datetime="20100101 00:00:00" --stop-datetime="20101231 23:59:59" host-bin.00003 > backup.sql

추출된 쿼리를 다음 명령어로 복구할 수 있다.

# mysql -uroot -p < backup.sql