binlog format에 따른 query handling & Isolation Level 선택

면접을 보다가 5년전에 합병할때 쯤 같은 문제를 다른 방식으로 처리함으로 인해 머리속에 기억났던 현상을 다시 한번 기억하게 되었다. 따로 기억하지 않은 듯 하여 기록해 두기로 한다.

 

1. Binlog Format에 따른 Query Handling 

STATEMENT 방식으로 REPEATABLE READ Isolation Level을 사용하여 MySQL을 운영하다 보면 다음과 같은 메세지를 Error Log에서 확인할 수 있다. 

[Warning] Unsafe statement written to the binary log using statement format since    BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This    is unsafe because the set of rows included cannot be predicted.

사용한 쿼리가 재 실행시 완벽히 재현되지 않는 안전하지 않은 쿼리라는 경고 메세지 이다. 

이련 경우에는 무조건 다음과 같은 케이스인지 확인하여 서비스팀에서 작성한 쿼리를 확인하고 조치를 취하게 조치하여 처리하곤 했다. (뭐 거의 8~9년전 이야기 이다.)

https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html

MySQL :: MySQL 8.0 Reference Manual :: 17.2.1.3 Determination of Safe and Unsafe Statements in Binary Logging

ROW나 MIXED가 5.1에서 나왔고, 5.5까지는 쓸만한지 확인못했던 시절부터 그렇게 해왔기 때문에 특별한 이유가 있지 않은 한 ROW로 포맷을 변경하지도 않았고, 쿼리를 안전하게 사용하는 방식으로 처리하게 가이드 했었다. (그 때는 ROW 포맷으로 인한 공간 부족 문제도 한몫했었다.)

하지만 이와 같은 문제는 ROW나 MIXED로 바이너리 로그 포맷을 변경하여 처리하는 것도 가능하다. 

MIXED로 변경하면 당연히 위와 같은 쿼리는 ROW방식으로 남길 것이기 때문이다. 

 

2. BInlog Format에 따른 Isolation Level 처리 

하지만 이 경우 외에도 MIXED,ROW방식으로 바이너리 로그 포맷을 변경해야 하는 경우가 있다. 바로 REPEATABLE READ Isolation이 아닌 READ-COMMITTED 방식으로 사용할 경우이다. READ-COMMITTED 방식은 하나의 트랜잭션에서 그 실행 시점에 따라 사용하는 스냅샷이 달라지기 때문에 STATEMENT 방식으로 바이너리 로그를 남기게 되면 어떤 시점 데이터로 처리 되었는지 명확히 맞출수가 없다. 그래서 무조건 ROW나 MIXED로 변경하기를 권장한다.