트랜잭션 너는 누구니?

When should I use transactions in my queries?

Basically any time you have a unit of work that is either sensitive to outside changes or needs the ability to rollback every change, if an error occurs or some other reason.

 

 

---

트랜잭션의 특징

---

트랜잭션의 특징은 크게 4가지로 구분된다. 

• 원자성 (Atomicity)

• 일관성 (Consistency)

• 독립성 (Isolation)

• 지속성 (Durability)

 첫번째로, 원자성은 트랜잭션이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것이다.  트랜잭션은 사람이 설계한

논리적인 작업 단위로서, 일처리는 작업단위 별로 이루어 져야 사람이 다루는데 무리가 없다.

만약 트랜잭션 단위로 데이터가 처리되지 않는다면, 설계한 사람은 데이터 처리 시스템을 이해하기 힘들 뿐만 아니라, 오작동 했을시 원인을 찾기가 매우 힘들어질것이다.

 두번째로, 일관성은 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것이다. 

트랜잭션이 진행되는 동안에 데이터베이스가 변경 되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는것이 아니라,

처음에 트랜잭션을 진행 하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 각 사용자는 일관성 있는 데이터를 볼 수 있는 것이다.

 세번째로, 독립성은 둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 경우에 어느 하나의 트랜잭션이라도 다른 트랜잭션의 연산을 끼어들 수 없다.  

하나의 특정 트랜잭션이 완료될때까지, 다른 트랜잭션이 특정 트랜잭션의 결과를 참조할 수 없다.

 네번째로, 지속성은 트랜잭션이 성공적으로 완료됬을 경우, 결과는 영구적으로 반영되어야 한다는 점이다.

---

** ACID 예시

 

** ACID 중 트랜잭션의 주 목표인 원자성과 고립성에 대해서 예시

 

(설계시에 고립성에 위배되는 사항이 없는지 확인이 주의 해야할 것 같다...)

 

 

---

트랜잭션의 Commit, Rollback 연산

---

 Commit이란 하나의 트랜잭션이 성공적으로 끝났고, 데이터베이스가 일관성있는 상태에 있을 때, 하나의 트랜잭션이 끝났다라는 것을

알려주기위해 사용하는 연산이다. 이 연산을 사용하면 수행했던 트랜잭션이 로그에 저장되며, 후에 Rollback 연산을 수행했었던 트랜잭션단위로 하는것을 도와준다.

Rollback이란 하나의 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션의 원자성이 깨진경우, 트랜잭션을 처음부터 다시 시작하거나, 트랜잭션의 부분적으로만 연산된 결과를 다시 취소시킨다.

후에 사용자가 트랜잭션 처리된 단위데로 Rollback을 진행할 수도 있다.

 

 

---

 

Transaction Rollback 시 당신의 레플리케이션 안전합니까?

 

내 생각은 Master MySQL의 slave에게 signal 주는 쓰레드가 일을 하지 않았기 때문에 별 문제 안 될거 같긴하다.

1.  마스터 테이블에 변화가 생김

2.  마스터 서버 프로그램이 바이너리 로그 기록 

3.  마스터 서버 시그널 프로그램이 변화에 대해서 전달

4.  슬레이브 서버 캡쳐 프로그램이 변화에 대해 받음

5.  슬레이브 테이블 동기화 기록 함

 

 

** 레퍼런스를 참고해서 개발자의 의견을 알아보자...

 

MySQL 5.7 Reference Manual  /  ...  /  Replication and Transactions

16.4.1.34 Replication and Transactions

Mixing transactional and nontransactional statements within the same transaction.  In general, you should avoid transactions that update both transactional and nontransactional tables in a replication environment. You should also avoid using any statement that accesses both transactional (or temporary) and nontransactional tables and writes to any of them.

The server uses these rules for binary logging:

• If the initial statements in a transaction are nontransactional, they are written to the binary log immediately. The remaining statements in the transaction are cached and not written to the binary log until the transaction is committed. (If the transaction is rolled back, the cached statements are written to the binary log only if they make nontransactional changes that cannot be rolled back. Otherwise, they are discarded.)

• For statement-based logging, logging of nontransactional statements is affected by the binlog_direct_non_transactional_updates system variable. When this variable is OFF (the default), logging is as just described. When this variable is ON, logging occurs immediately for nontransactional statements occurring anywhere in the transaction (not just initial nontransactional statements). Other statements are kept in the transaction cache and logged when the transaction commits. binlog_direct_non_transactional_updates has no effect for row-format or mixed-format binary logging.

 

뭔소리인지 모르겠다... 그만 알아보도록 하자