4. binlog_direct_non_transactional_updates 이란 무엇인가??

못 보던 variable이라 궁금해서 먼가 해서 찾아봤습니다. 

5.1.44부터 새롭게 추가된 variable 이네요.

동시성의 이슈중의 하나로 슬레이브 서버에서 하나의 트랜잭션 안에 트랜잭션을 지원하는 테이블과 지원하지 않은 테이블에 대한 변경작업이 동시에 발생하는 경우 모순될 수 있었다고 하네요. 

[MySQL tries to preserve causality among these statements by writing non-transactional statements to the transaction cache, which is flushed upon commit. However, problems arise when modifications done to nontransactional tables on behalf of a transaction become immediately visible to other connections because these changes may not be written immediately into the binary log.]

MySQL reference에 나와있는 위 구문을 해석해 보니, [ MySQL은 이런 문장들 사이에서 인과관계를 보호하기 위해  트랜잭션을 지원하지 않은 문장을 transaction cache에 넣고, commit시에 flush 한다. 하지만, 문제는 이 내역이 즉시 binary log에 기록되지 않음에도 트랜잭션 안에서 트랜잭션을 지원하지 않는 테이블에 발생한 변경내역은 바로 다른 커낵션들이 볼 수 있다는 사실이다. ]

대충 요렇게 해석되는거 같네요...

흠냐....이렇다면 문제겠군요...머 그래서 저는 왠만하면 같이 쓰지 말라고 하죠.....ㅋㅋ

어쨌건...그래서 

5.1.44에서 이 variable을 추가했다고 하는 군요.  

이 옵션은 default는 disable이네요. 이 옵션을 enable하게 되면 binary log에 바로 변경내역을 작성한다고 하네요....흠...이게 문제를 해결한 건지는 몰겠지만..왠지 땜빵 같다는 느낌은 들지만..머..........

어쨌든..근데...binary log format이 statement, mixed일때만 사용가능하다고 하는군요......

흠.....

마지막으로 중요한 사항이 하나 있네요...

다음과 같이 연관관계가 있게 sql이 실행되면 안된다고 하네요....

INSERT INTO myisam_table SELECT * FROM innodb_table.

이렇게 쓰면 완전 꼬인데요...함부로 쓰면 안되겠군요....

그냥 제 생각엔 안섞어 쓰는게 제일인거 같네요.....

다른것 보다가 잼있는거 하나 건졌네요..ㅋㅋ