MySQL Binary log의 일관성 유지

MySQL Binary log의 일관성 유지

MySQL Binary log는 매번 디스크와 동기화시키지 않는 것이 Default 설정이다.

그래서, 만약, 운영 체제나 장비(MySQL만의 장애가 아닌) 장애가 발생하면, Binary log의 마지막 부분들을 소실될 가능성이 있다.

이러한 손실을 막기 위해서, sync_binlog 시스템 변수를 설정하여 Binary log가 매 N개의 쿼리 이후 디스크와 동기화되도록 설정할 수 있다.

sync_binlog 옵션으로 1을 설정하는 것이 가장 안정적이지만, 가장 느린 방식이기도 하다.

하지만, sync_binlog를 1로 설정했다 하더라도, 여전히 시스템의 장애가 발생했을 때, 데이터베이스의 내용과 Binary log의 내용이 일치하지(일관되지) 않을 가능성이 있다.

예를 들어서, InnoDB 엔진을 사용하는 테이블에서 COMMIT이 실행되면, MySQL은 모든 트랜잭션 쿼리들을 Binary log에 기록하고 그 이후 InnoDB의 트랜잭션을 Commit하게 되는데,

만약, 이 두 조작 사이에 MySQL 서버에 장애가 발생하게 되면, InnoDB의 트랜잭션은 Rollback되지만, Binary log에서 그 쿼리는 지워지지 않고 그대로 남아 있게 된다.

이러한 문제를 해결하기 위해서는 innodb_support_xa 시스템 변수를 1로 설정해야 한다.

이 시스템 변수는 또한 InnoDB의 XA 트랜잭션과도 연관을 가지게 되며, Binary log와 InnoDB 데이터의 동기화도 보장하는 역할도 한다.

==> 하지만, sync_binlog=1 설정은 상당한 Disk 비용을 지불해야만 한다.

    (자세한 내용은 sysbench로 벤치마킹을 실행해보면 쉽게 알 수 있다)

==> 일반적으로 다들 별로 신경 안써지만, sync_binlog=1인 설정에서는

    Binary log에 트랜잭션 쿼리(또는 레코드)가 기록되고, fsync(파일 동기화)가 되어야지만, 

    비로소 InnoDB의 트랜잭션이 Commit될 수 있다는 것을 명심해야 한다.

==> sync_binlog를 1 이외의 값으로 설정하는 것과, Replication의 delay는 전혀 무관하며,

    sync_binlog 값의 설정은 Binary log의 Disk 동기화만 관리하게 된다.

==> sync_binlog=0으로 설정하게 되면, Binary log의 Disk 동기화는 MySQL이 아닌 운영체제에 의해서

    진행되며(처리되며), 일반적으로 EXT3와 같은 File system은 5초 주기로 Cache를 Flush하는 것으로 알려져 있다.