트랜잭션
여러개의 변경 작업을 수행하는 쿼리가 조합됐을 때 이상이 있을경우 원래 상태로 돌아가게 해주는 기능
논이적인 작업 셋 자체가 100% 적용되거나(COMMIT을 실행했을 때) 아무것도 적용되지 않아야(ROLLBACK) 함을 보장해줌
INNODB는 쿼리 중 일부라도 오류가 발생하면 전체를 원 상태로 만든다는 트랜잭션의 원칙대로 INSERT문을 실행하기 전 상태로 그대로 복구함
MyISAM 테이블에서 발생하는 이러한 현상을 부분 업데이트라고 표현 - 부분 업데이트 현상은 테이블 데이터의 정합성을 맞추는데 상당히 어려운 문제를 만들어냄
트랜잭션은 어플리케이션 개발에서 고민해야할 문제를 줄여주는 아주 필수적인 DBMS의 기능
주의사항
트랜잭션 또한 DBMS의 커넥션과 동일하게 꼭 필요한 최소의 코드에만 적용하는것이 좋음
코드에서 트랜잭션의 범위를 최소화 하는것이 좋음
실제 트랜잭션의 시작은 5번
2,3,4 절차가 빨리 진행되도 트랜잭션에 포함 시킬 이유는 없음
8번 메일전송이나 FTP 파일 전송작업, 네트워크를 통해 원격서버와 통신하는 작업은 트랜잭션에서 제외하는 것이 좋음
5,6번은 하나의 트랜잭션으로 묶고, 7번은 단순 조회 작업이므로 트랙잭션에 포함하지 않아도됨
코드에서 데이터베이스 커넥션을 가지고 있는 범위와 트랜잭션이 활성화돼 있는 프로그램의 범위를 최소화 해야함
MySQL 엔진의 잠금
스토리지 엔진 레벨 잠금
MySQL 엔진 레벨 잠금 - 스토리지 엔지을 제외한 나머지 부분
MySQL 엔진 레벨의 잠금은 모든 스토리지 엔진에 영향을 미치지만, 스토리지 엔진 레벨의 잠금은 상호간의 영향을 미치지 않음
테이블 락 - 테이블 데이터 동기화
메타데이터 락 - 테이블의 구조를 잠금
네임드 락 - 사용자의 필요에 맞게 사용
글로벌 락
FLISH TABLES WITH READ LOCK 명령으로 획득
잠금 가운데 가장 범위가 큼
글로벌 락을 획득하면 다른 세션에서 SELECT를 제외한 대부분의 DDL문장이나 DML 문장을 실행하는 경우 글로벌 락이 해제 될 때까지 해당 문장이 대기상태로 남음
영향을 미치는 범위는 MySQL 서버 전체
글로벌 락은 모든 테이브레 큰영향을 미치기 때문에 웹서비스용으로 사용되는 MySQL 서버에서는 가급적 사용하징 않는것이 좋음
특정 세션에서 백업 락을 획득하면 모든 세션에서 다음과 같이 테이블의 스키마나 상요자의 인증관련 정보를 변경할 수 없음
데이터베이스 및 테이블 등 모든 객체 생성 및 변경, 삭제
REPAIR TABLE과 OPTIMIZE 명령
사용자 관리 및 비밀번호 변경
백업 락은 일반적인 테이블의 변경은 허용됨
주로 백업은 레플리카 서버에서 실행됨
MySQL 서버의 백업락은 정상적으로 복제는 실행되지만, 백업의 실패를 막기위해 DDL 명령이 실행되면 복제를 일시 중지하는 역할
테이블 락
개별 테이블 단위로 설정되는 잠금
LOCK TABLES table_name [READ|WRITE] 명령으로 특정 테이블의 락을 획득함
명시적으로 획득한 잠금은 UNLOCK TABLES명령으로 잠금을 반납(해제)
명시적인 테이블 락도 특별한 상황이 아니면 어플리케이션에서 사용할 일은 없음
묵시적인 테이블 락은 MySQL, MEMORY 테이블에 데이터를 변경하는 쿼리를 실행하면 발생함
MySQL 서버가 데이터가 변경되는 테이블에 잠금을 설정하고 데이털르 변경한 후, 즉시 잠금을 해제하는 형태로 사용
묵시적인 테이블 락은 쿼리가 실행되는 동안 자동으로 획득했다가 쿼리가완료된 후 자동 해제됨
InnoDB 테이블의 경우 스토리지 엔진 차원에서 레코드 기반의 잠금을 제공하기 때문에 단순데이터 변경 쿼리로 인해 묵시적인 테이블 락이 성정되지는 않음
테이블락이 성정되지만, 대부분의 데이터 변경(DML) 워리에서는 무시되고 스키마를 변경하는 뭐리의 경우에만 영향을 미침
네임드 락
GET_LOCK() 함수를 이용해 임의의 문자열에 대해 잠금을 설정 할 수 있음
잠금의 특징은 대상이 테이블이나 레코드 또는 AUTO_INCREMENT와 같은 데이버베이스 객체가 아님
자주 사용은 안됨
메타데이터 락
메타데이터 락은 데이터베이스 객체(테이블이나 뷰)의 이름이나 구조를 변경하는 경우에 획득하는 잠금
RENAME TABLES tb_a TO tb_b 같이 테이블의 이름을 변경하는 경우 자동으로 획득하는 잠금
실시간으로 테이블을 바꿔야 하는 요건이 배치 프로그램에서 자주 발생
RENAME TABLE 명령문에 두개의 RENAME 작업을 한꺼번에 실행하면 실제 어플리케이션에서 아주 짧지만 rank테이블이 없는 순간이 존재하여 에러 발생
에러 발생없이 변경 가능
메타데이터 잠금과 InnoDB의 트랜잭션을 동시에 사용하는 경우
테이블의 구조를 변경해야하는 경우
온라인 DDL을 사용하면 단일 스레드로 작동하기 때문에 많은 시간이 소요됨
새로운 테이블을 생성하고 최근 데이터를 여러개의 스레드로 빠르게 복사하고
나머지 데이터는 트랜잭션과 테이블 잠금, RENAME 으로 프로그램 중단없이 실행
미리 데이터를 복사 해야 잠금시간을 최소화하여 서비스에 미치는 영향을 줄일 수 있음