2023.01.24 문제 목록 (ch05)

[sedin2]

📌 문제목록

번호	출제자	문제
1.	ramirami	MySQL의 잠금 중, 네임드락만 분산락을 구현할 수 있나요? 그렇다면 그 이유는 무엇인가요?
2.	ramirami	REPEATABLE READ 격리수준에선 왜 NON-REPEATABLE READ 문제가 발생하지 않는 건가요?
3.	ramirami	index lock은 update 쿼리가 실행될 때 사용된다고 하는데요. 매번 필수적으로 잠금을 사용하는 것인가요?
4.	giibeom	자동 증가 락은 무엇이고 어떤 경우에 적용되는 잠금인가요?
5.	giibeom	격리수준에서 READ_COMMITTED 모드와 REPEATABLE_READ 모드에 차이점을 간략하게 설명해주세요
6.	giibeom	REPEATABLE_READ 트랜잭션 관련 예시(181쪽, 182쪽)를 활용한 QUIZ (스터디 때 공개) ------------------------------------------------------------------------------------------------------------ 만약 181쪽 그림에서는 10번에서 SELECT 걸고 12번이 중간에 데이터를 변경해도 트랜잭션 번호가 앞이니까 그대로 아까의 SELECT를 그대로 가져온다 그렇다면 중간에 8번 트랜잭션이 중간에 데이터를 변경할 경우에는 10번 트랜잭션의 SELECT 문은 그대로 유지될까?
7.	ZooKong	실시간으로 많은 양의 Insert가 발생하는 로그 테이블에 대해 테이블 구조를 변경해야 할 경우, 작업 계획과 각 단계별 이유를 설명해주세요
8.	ZooKong	트랜잭션 설계시에 주의할 점이 무엇이 있는지와 이유를 설명해주세요
9.	sedin2	레코드 락(Record Lock), 갭 락(Gap Lock), 넥스트 키 락(Next Key Lock)에 대해 각각 설명 해 주세요
10.	sedin2	InnoDB 스토리지 엔진의 REPEATABLE-READ 격리 수준에선 PHANTOM-READ 부정합이 발생하지 않는데 어떻게 이게 가능 할까요?
11.	sedin2	네임드 락(Named Lock)에 대해 설명 해 주세요

[zookong]

1. MySQL의 잠금 중, 네임드락만 분산락을 구현할 수 있나요? 그렇다면 그 이유는 무엇인가요?

• 네임드 락을 통해 분산 락을 구현하기 쉬운 것은 맞으나 다른 방법도 존재
  • 추가적으로 MySQL 클러스터 환경에서 단일 서버에 대해서만 잠금을 설정하므로 적절하지 않을 것으로 알고 있습니다.(단일 서버는 상관 X)
• 생각해본 방법
  • 유니크 인덱스를 통한 INSERT와 DELETE를 통해서도 괜찮을 것 같습니다.
  • 지속적인 DELETE를 통해 락을 수행하고 성공시에 로직 수행 후 다시 INSERT로 돌려놓는 행위 형식입니다.
  • 이 또한 DELETE에 대해 스핀 락 형태로 생각해보았습니다.
  • 락을 걸 수 있는 칼럼과 시간 칼럼을 추가하여 update 시에 인덱스 락을 통해 잠근 후 ttl 과 같은 값을 넘겨 시간 칼럼과 비교 후 ttl을 넘을 경우 특정 다른 칼럼을 업데이트 하면서 결과를 받아 동시성을 제어하는 방법도 있을 것 같습니다

2. REPEATABLE READ 격리수준에선 왜 NON-REPEATABLE READ 문제가 발생하지 않는 건가요?

• NON-REPEATABLE READ 정의
  • 한 트랜잭션 안에서 같은 쿼리를 두번 실행 했을 때, 다른 값이 나오는 Read 현상
• REPEATABLE READ 격리 수준에서 발생하지 않는 이유
  • Undo 영역에 백업된 이전 데이터를 이용해 트랜잭션 내에서 동일한 결과를 보장
  • 트랜잭션 시작시에 스냅샷을 생성하고 해당 스냅샷을 통해 데이터를 조회한다고 생각

3. index lock은 update 쿼리가 실행될 때 사용된다고 하는데요. 매번 필수적으로 잠금을 사용하는 것인가요?

• 사용자가 지정한 인덱스에 한정한 인덱스 락이라는 의미로 사용하였다면 항상은 아님
  • 테이블에 사용자 정의 인덱스가 없더라도 자동 생성된 내부적인 클러스터 인덱스를 이용하여 레코드 락을 수행

4. 자동 증가 락은 무엇이고 어떤 경우에 적용되는 잠금인가요?

• 테이블에 자동 증가하는 숫자 값을 추출하여 사용하는 칼럼 속성을 제공 (AUTO_INCREMENT)
• 레코드를 새로 저장하는 쿼리에 대해 자동 증가 락(AUTO_INCREMENT 락)이라는 테이블 수준의 잠금을 사용

5. 격리수준에서 READ_COMMITTED 모드와 REPEATABLE_READ 모드에 차이점을 간략하게 설명해주세요

• READ_COMMITTED
  • Undo log를 활용하여 커밋되기 전의 레코드 값에 대해 조회
  • 커밋이 완료가 된 트랜잭션의 내용에 대해서는 조회가능
• REPEATABLE_READ
  • 동일 트랜잭션 내에서는 Undo log를 활용하여 트랜잭션 시작시의 시점 레코드 값을 보장
  • 중간에 다른 트랜잭션이 커밋을 완료하더라도 동일한 Undo log에서 조회

6. REPEATABLE_READ 트랜잭션 관련 예시(181쪽, 182쪽)를 활용한 QUIZ (스터디 때 공개)

7. 실시간으로 많은 양의 Insert가 발생하는 로그 테이블에 대해 테이블 구조를 변경해야 할 경우, 작업 계획과 각 단계별 이유를 설명해주세요

• 로그를 백업할 신규 테이블 생성
  • 기존 테이블에 칼럼을 추가할 경우 언두 로그 증가와 DDL이 실행되는 동안의 버퍼 크기가 커질 수 있음, 또한 DDL은 단일 스레드로 작동하기에 오래 걸림
• INSERT .. SELECT 와 같은 명령어를 통해 백업 테이블로 최대한 최근 데이터까지 백업 데이블에 INSERT
  • 남은 데이터를 복사하는 동안 테이블의 잠금으로 인해 INSERT가 불가할 수 있기 때문
• RENAME을 하나의 명령어로 실행해서 테이블 명칭을 교환
  • 명령어를 나눠서 실행할 경우 짧은 시간 사이에 테이블이 없다고 할 수 있음
• 나머지 데이터를 마저 INSERT .. SELECT

8. 트랜잭션 설계시에 주의할 점이 무엇이 있는지와 이유를 설명해주세요

• 메일 전송, FTP와 같은 네트워크를 통한 작업은 트랜잭션에 포함하지 않는 것을 권장
• 이미 저장한 정보를 확인용 조회를 트랜잭션에 포함하지 않는 것을 권장
• 전체 흐름에서 크게 벗어나는 내용의 DB 작업은 별도의 트랜잭션으로 관리하는 것을 권장

9. 레코드 락(Record Lock), 갭 락(Gap Lock), 넥스트 키 락(Next Key Lock)에 대해 각각 설명 해 주세요

• 레코드 락
  • 레코드 자체만을 잠그는 것을 레코드 락이라고 함
  • InnoDB 스토리지 엔진은 레코드 자체가 아닌 인덱스의 레코드를 잠금
  • 프라이머리 키, 유니크 인덱스에 의한 변경 작업은 해당 락만 사용
• 갭 락
  • 레코드 자체가 아닌 레코드와 바로 인접한 레코드 사이의 간격을 잠금
  • 넥스트 키 락의 일부로 자주 사용
• 넥스트 키 락
  • 레코드 락과 갭 락을 합쳐 놓은 형태의 잠금

10. InnoDB 스토리지 엔진의 REPEATABLE-READ 격리 수준에선 PHANTOM-READ 부정합이 발생하지 않는데 어떻게 이게 가능 할까요?

• InnoDB 스토리지 엔진에서는 넥스트 키 락을 통해 PHANTOM-READ를 방지
• 다른 트랜잭션이 함부로 넥스트 키 락을 통해 잠금하고 변경하지 못하도록 방지, 이를 통하 팬텀 리드 현상을 방지

11. 네임드 락(Named Lock)에 대해 설명 해 주세요

• 임의의 문자열에 대해 잠금 설정
  • 단순히 사용자가 지정한 문자열에 대한 락 획득, 반납
• 다수의 어플리케이션이 존재 하더라도 네임드 락을 통해 특정 도메인에 대해 동기화로 활용 가능

[sedin2]

1. MySQL의 잠금 중, 네임드락만 분산락을 구현할 수 있나요? 그렇다면 그 이유는 무엇인가요?

• 단일 DB서버일 경우 간단하게 구현 가능하다.
• 네임드 락은 임의의 문자열에 대해 잠금을 거는 것이기 때문에
• 잠금 획득 가능 한지 체크 -> 잠금 획득이 가능 -> 잠금을 획득 한 후 로직을 처리 -> 잠금을 반납
• 잠금 획득 가능 한지 체크 -> 잠금 획득이 불가능 -> 잠금 획득을 위해 웨이팅 -> 다시 체크

  2. REPEATABLE READ 격리수준에선 왜 NON-REPEATABLE READ 문제가 발생하지 않는 건가요?

• 현재 실행중인 트랜잭션의 가시범위는 현재 자신의 트랜잭션 ID보다 작은 트랜잭션들만 볼 수 있다.
• 이를 통해 일관된 읽기를 보장한다.
• 만약 10번 트랜잭션에서 읽은 데이터가 8번 트랜잭션에서 커밋된 데이터이고, 9번 트랜잭션은 실행 중 일때 (9, 10번 트랜잭션은 아직 실행 중인 상태) 9번 트랜잭션에서 10번 트랜잭션에서 읽은 데이터를 수정 하더라도 일관된 읽기를 보장 해 준다.
• 동일한 트랜잭션 내에서 일관된 읽기는 첫 번째 읽기로 설정된 스냅샷을 읽기 때문에
• MySQL Snapshot

  3. index lock은 update 쿼리가 실행될 때 사용된다고 하는데요. 매번 필수적으로 잠금을 사용하는 것인가요?

• Update 쿼리의 WHERE 조건문에 해당하는 인덱스가 있다면 해당 인덱스를 통해 잠금을 할 것이다.
• 인덱스가 없다면 내부적으로 생성되는 클러스터 인덱스를 통해 테이블 풀 스캔을 통해 모든 레코드를 잠글 것이다.

  4. 자동 증가 락은 무엇이고 어떤 경우에 적용되는 잠금인가요?

• 자동 증가 락은 Insert or Replace 같은 새로운 레코드를 저장하는 쿼리에서만 필요하다.
• 명시적으로 획득하고 해제하는 방법은 없으며, 아주 짧은 시간동안 걸렸다 해제되는 잠금이라 대부분의 경우 큰 문제 발생 X
• 락을 걸며 자동 증가 숫자 값을 채번하기 때문에 해당 숫자값은 유니크하다.

  5. 격리수준에서 READ_COMMITTED 모드와 REPEATABLE_READ 모드에 차이점을 간략하게 설명해주세요

• READ_COMMITTED는 커밋이 완료된 데이터를 읽을 수 있으며, Dirty Read가 발생하지 않는다. 하지만 같은 트랜잭션 내에서 처음 읽은 조회 쿼리 결과가 두 번째 읽은 같은 쿼리의 결과가 동일하지 않을 수 있다. (REPEATABLE_READ 부정합이 발생)
• REPEATABLE_READ는 앞서 말한 Dirty Read, REPEATABLE_READ 부정합이 발생하지 않는다. MySQL InnoDB 스토리지 엔진은 Phantom Read 또한 일어나지 않는다.

  6. REPEATABLE_READ 트랜잭션 관련 예시(181쪽, 182쪽)를 활용한 QUIZ (스터디 때 공개)

  7. 실시간으로 많은 양의 Insert가 발생하는 로그 테이블에 대해 테이블 구조를 변경해야 할 경우, 작업 계획과 각 단계별 이유를 설명해주세요

• 언두 로그 증가와 Online DDL 버퍼 크기 등 고민 해야할 문제점이 많다.
• MySQL DDL은 단일 스레드로 동작하기 때문에 상당한 시간이 소모될 것이다.
• 변경해야할 새로운 구조의 로그 테이블을 만든다.
• 여러 개의 스레드로 원본 로그 테이블로부터 복사 한다. (1시간 직전 또는 하루 전의 데이터 까지) 프라이머리 키를 범위별로 나누어 복사 진행
• 복사가 완료되면 현재 시점까지의 복사를 진행한다.
• 현재 시점까지 복사가 완료되기 전까지 테이블이 잠기기 때문에 원본 로그 테이블에 INSERT 할 수 없다.
• 가능한 아주 최근 데이터까지 복사해야 잠금 시간을 최소화 할 수 있다.

  8. 트랜잭션 설계시에 주의할 점이 무엇이 있는지와 이유를 설명해주세요

• 꼭 필요한 시점에 데이터베이스 커넥션을 시작해야 한다. 애플리케이션 단에서 사용자 요청에 대한 검증하기 전 부터 커넥션을 열면 불 필요한 리소스 낭비이다. 트래픽이 많이 몰리는 서비스 이라면 치명적일 것이다.
• 애플리케이션 단에서 같은 트랜잭션 내에 네트워크를 통해 외부와 통신하는 로직등은 반드시 빼야한다. 외부 서버와 통신 할 수 없는 상황이라면 DBMS 서버도 위험 할 수 있다.

  9. 레코드 락(Record Lock), 갭 락(Gap Lock), 넥스트 키 락(Next Key Lock)에 대해 각각 설명 해 주세요

• 레코드 락은 레코드 자체만을 잠그는 것을 뜻한다.
  • InnoDB 스토리지 엔진은 레코드 자체가 아니라 인덱스의 레코드를 잠근다.
• 갭 락은 레코드와 바로 인접한 레코드 사이의 간격만을 잠그는 것을 의미
  • 레코드와 레코드 사이에 새로운 레코드가 생성(INSERT)되는 것을 제어한다.
• 넥스트 키 락은 레코드 락 + 갭 락을 합쳐놓은 형태의 잠금을 의미한다.
  • 바이너리 로그에 기록되는 쿼리가 레플리카 서버에서 실행될 때 소스 서버에서 만들어 낸 결과와 동일한 결과를 만들어내도록 보장하는 것이 주목적

    10. InnoDB 스토리지 엔진의 REPEATABLE-READ 격리 수준에선 PHANTOM-READ 부정합이 발생하지 않는데 어떻게 이게 가능 할까요?

• SELECT ... FOR UPDATE, SELECT ... FOR SHARE 쿼리는 넥스트 키 락을 이용해 인덱스의 레코드를 잠근다.
• 이를 통해 INSERT, UPDATE, DELETE를 막는다.
• MySQL Phantom Rows
• MySQL Repeatable Read

  11. 네임드 락(Named Lock)에 대해 설명 해 주세요

• 네임드 락은 임의의 문자열에 대해 잠금을 설정할 수 있다.
• GET_LOCK(), RELEASE_LOCK() 함수를 통해 락을 얻고 반납할 수 있다.
• 네임드락이 잠그는 대상은 테이블이나 레코드 또는 AUTO_INCREMENT와 같은 데이터베이스 객체가 아니다.

[gzgzg2]

1. MySQL의 잠금 중, 네임드락만 분산락을 구현할 수 있나요? 그렇다면 그 이유는 무엇인가요?

• MySQL의 네임드 락으로 동시성 문제를 해결하려면, 일단 분산 서버에서 단일 데이터베이스라는 조건이 만족되어야 한다.
• 네임드 락으로 분산락을 구현하는 이유는 애플리케이션에서 각 트랜잭션이 동시에 수행되면서 인덱스의 순서가 일치하지 않도록 로직을 구현하면 데드락이 발생할 확률이 높아진다. 이유는 각 트랜잭션에서 다른 트랜잭션에서 획득한 락을 서로 해제될 때까지 기다릴 수 있기 때문이다.
• 네임드 락은 데이터에 락을 거는 것이 아닌 문자열에 락을 걸기 때문에 해당 문자열의 락을 획득하지 못하면 데이터를 획득할 수 없게 미리 예방할 수 있다.

2. REPEATABLE READ 격리수준에선 왜 NON-REPEATABLE READ 문제가 발생하지 않는 건가요?

• REPEATABLE READ 격리수준에선 실행된 트랜잭션 ID 보다 버전이 높은 트랜잭션의 정보는 읽을 수 없기 때문이다. 한 트랜잭션이 실행되고 이후에 변경된 정보는 이전 트랜잭션에서 읽을 수 없다.

3. index lock은 update 쿼리가 실행될 때 사용된다고 하는데요. 매번 필수적으로 잠금을 사용하는 것인가요?

• 인덱스가 설정되어 있지 않으면 내부적으로 생성되는 클러스터 인덱스를 사용하기 때문에 필수적으로 잠금이 사용된다고 생각한다.

4. 자동 증가 락은 무엇이고 어떤 경우에 적용되는 잠금인가요?

• INSERT나 REPLACE 같이 새로 데이터를 추가하는 쿼리에서 발생하는 잠금이다. AUTO_INCREMENT 값을 중복되지 않은 일정한 순서로 증가시키기 위해 사용된다.

5. 격리수준에서 READ_COMMITTED 모드와 REPEATABLE_READ 모드에 차이점을 간략하게 설명해주세요

• READ_COMMITTED 모드는 트랜잭션 버전과 관계없이 커밋된 레코드를 읽을 수 있다. REPEATABLE_READ는 실행 중인 트랜잭션 ID보다 높은 트랜잭션 ID의 변경내용을 확인할 수 없다.

6. REPEATABLE_READ 트랜잭션 관련 예시(181쪽, 182쪽)를 활용한 QUIZ (스터디 때 공개)

• REPEATABLE_READ 격리수준일 경우 실행된 트랜잭션 ID 보다 높은 트랜잭션의 변경 정보를 확인할 수 없다.

7. 실시간으로 많은 양의 Insert가 발생하는 로그 테이블에 대해 테이블 구조를 변경해야 할 경우, 작업 계획과 각 단계별 이유를 설명해주세요

• RENAME 테이블 명령어를 실행하기전에 범위별로 데이터를 미리 옮겨둔다.
  • 범위별로 데이터를 옮기는 이유는 동시에 여러 스레드로 빠르게 작업을 처리하기 위함과 락의 범위를 최소화 하기 위함이다.
• 데이터가 전부 옮겨지면 RENAME 명령어로 테이블 명을 수정한다.
  • 데이터를 옮기기 전에 RENAME을 수행하지 않는 이유는 RENAME 명령어가 실행될 때 메타데이터 락을 획득하기 때문이다. RENAME이 수행이 완료되기 전까지 INSERT 명령어는 대기해야 된다.

8. 트랜잭션 설계시에 주의할 점이 무엇이 있는지와 이유를 설명해주세요

• 하나의 트랜잭션에서 트랜잭션과 관계없는 로직을 트랜잭션 시작과 종료사이에 배치하지 않는 것
  • 트랜잭션 사이에 DBMS와 연관없는 로직이 자리잡게 되면 DBMS 처리와 관계없이 트랜잭션이 오랜시간동안 유지된다. 하나의 트랜잭션이 길어질 수록 DBMS의 전체적인 성능 저하가 발생할 수 있다.
• 하나의 쿼리가 실패했을 때 전체 쿼리가 롤백되어야 하는 경우 한 트랜잭션에 배치해야 한다. 그렇지 않으면 하나의 쿼리가 실패했을 때 이전에 성공한 쿼리의 변경 사항을 직접 삭제해야하는 번거로운 작업이 요구될 수 있다.

9. 레코드 락(Record Lock), 갭 락(Gap Lock), 넥스트 키 락(Next Key Lock)에 대해 각각 설명 해 주세요

• 레코드 락이란 레코드에 락을 거는 것. innodb에선 인덱스에 락을 걸게 된다.
• 갭 락이란 레코드와 레코드 사이 간격에 락을 거는 것이다.
• 넥스트 키 락이란 레코드 락과 갭 락이 합쳐진 것이다. 레코드와 레코드 사이의 간격에 전부 락을 걸게된다.

10. InnoDB 스토리지 엔진의 REPEATABLE-READ 격리 수준에선 PHANTOM-READ 부정합이 발생하지 않는데 어떻게 이게 가능 할까요?

• REPEATABLE_READ는 검색 조건으로 사용되는 레코드 범위에 넥스트 키 락을 걸게된다. 때문에 해당 트랜잭션이 종료될 때까지 다른 트랜잭션이 검색조건 사이에 값을 쓸 수 없게 된다.

11. 네임드 락(Named Lock)에 대해 설명 해 주세요

• 네임드 락이란 유저 수준의 LOCK이다. 특징으로는 데이터베이스 객체에 잠금을 거는 것이 아닌, 문자열 자체에 잠금을 거는 것이 있다. GET_LOCK 명령어로 획득하고 RELEASE_LOCK 명령어로 해제할 수 있다.
• 특이사항으론 동일 커넥션에서 여러번 GET_LOCK 을 획득하면 락을 해제할 때 획득한 수 만큼 RELEASE_LOCK 명령어를 실행해줘야 한다.

[giibeom]

1. MySQL의 잠금 중, 네임드락만 분산락을 구현할 수 있나요? 그렇다면 그 이유는 무엇인가요?

--- 이게 무엇이람

2. REPEATABLE READ 격리 수준에선 왜 NON-REPEATABLE READ 문제가 발생하지 않는 건가요?

• REPEATABLE READ에서는 해당 트랜잭션 내 반복된 읽기를 지원하기 위해 SELECT 시 해당 operation을 수행한 시간을 기록하여 현재 시점의 스냅샷을 만듭니다
• 이후에 들어오는 조회들은 해당 스냅샷을 기준으로 SELECT가 이루어집니다
• https://dev.mysql.com/doc/refman/8.0/en/glossary.html - consistent_read

---

3. index lock은 update 쿼리가 실행될 때 사용된다고 하는데요. 매번 필수적으로 잠금을 사용하는 것인가요?

• 일반적으로는 update 시 조건 절에 있는 컬럼을 토대로 스캔된 레코드에는 인덱스 락이 걸리는데요
• 하지만 프라이머리 키 또는 유니크 인덱스에 의한 변경 작업은 레코드 자체에만 락을 거는 것으로 알고 있습니다

---

4. 자동 증가 락은 무엇이고 어떤 경우에 적용되는 잠금인가요?

• 자동 증가 락은 레코드를 새로 생성하는 문장인 INSERT와 REPLACE 쿼리가 실행될 때 적용되는 잠금입니다
• AUTO_INCREMENT가 여러 ROW가 동시에 실행 될 시 중복되면 안되기 때문에 일시적으로 아주 짧은 시간동안 테이블 수준의 잠금을 거는 특징이 있습니다
• 또한 MySQL 5.1부터는 시스템 변수를 통해서 자동 증가 락의 작동 방식을 변경할 수 있습니다

---

5. 격리 수준에서 READ_COMMITTED 모드와 REPEATABLE_READ 모드에 차이점을 간략하게 설명해주세요

• READ_COMMITTED와 REPEATABLE_READ의 가장 큰 차이점은 두가지이다
• 첫번째로는 언두 영역의 트랜잭션 번호를 통해 몇 번째 이전 버전까지 찾아 들어가는지의 차이
• 두번째로는 스냅샷을 통한 일관된 읽기를 지원하는지 OR NON-REPEATABLE READ 부정합이 발생하는지

---

6. REPEATABLE_READ 트랜잭션 관련 예시(181쪽, 182쪽)를 활용한 QUIZ (스터디 때 공개)

• 2번의 정답과 일치하는 문제
• 만약 181쪽 그림에서는 10번에서 SELECT 걸고 12번이 중간에 데이터를 변경해도 트랜잭션 번호가 앞이니까 그대로 아까의 SELECT를 그대로 가져온다
• 그렇다면 중간에 8번 트랜잭션이 중간에 데이터를 변경할 경우에는 10번 트랜잭션의 SELECT 문은 그대로 유지될까?

---

7. 실시간으로 많은 양의 Insert가 발생하는 로그 테이블에 대해 테이블 구조를 변경해야 할 경우, 작업 계획과 각 단계별 이유를 설명해주세요

• 먼저 짚어야될 점은 MySQL에서의 DDL은 싱글 스레드로 굉장히 느리다는 단점이 있고, 느린 만큼 테이블 락이 오래 걸려있다는 점
• 따라서 작업은 3가지로 이루어져야 한다
  1. 변경할 구조의 테이블을 새로 생성한다
  2. 가능한 제일 최신 데이터까지 pk 범위를 나눠 멀티 스레드로 복사 하여 새로 생성한 테이블로 INSERT
  3. 나머지 잔여 데이터는 테이블 쓰기 락을 걸고 마저 복사한다 (이 때는 테이블 INSERT가 불가)
  4. 복사가 완료되면 RENAME을 통해 새로 생성한 테이블을 기존 테이블 명으로, 기존 테이블 명을 old를 붙인 다른 테이블 명으로 변경
     • RENAME을 통해 테이블 명을 한번에 변경할 시 일시적으로 메타데이터 락을 통해 아주 짧은 순간의 테이블을 못찾는 상황을 방지할 수 있다
  5. old 테이블 삭제

---

8. 트랜잭션 설계시에 주의할 점이 무엇이 있는지와 이유를 설명해주세요

• 트랜잭션을 설계할 때는 무조건 범위를 최소화 하는 것이 좋다
• 또한 외부 네트워크 통신 작업은 절대 트랜잭션 안에 포함시키지 말자..
  • DB 커넥션의 개수는 한정되어있다.
  • 만약 외부 네트워크 통신이 오류로 인해 해당 트랜잭션이 DB 커넥션을 계속 물고 있다면 DB 서버도 제 기능을 못하게 될 수도 있다

---

9. 레코드 락(Record Lock), 갭 락(Gap Lock), 넥스트 키 락(Next Key Lock)에 대해 각각 설명 해 주세요

• 레코드락 : 레코드 단위의 잠금. InnoDB 스토리지 엔진에서는 인덱스 단위 잠금
• 갭 락 : 레코드와 레코드 사이에 INSERT를 제어하는 잠금
• 넥스트 키 락 : 레코드 락과 갭락이 합쳐진 잠금. 소스 서버와 레플리카 서버에서 동일하게 복제되는 것을 보장하는 것이 주 목적

---

10. InnoDB 스토리지 엔진의 REPEATABLE-READ 격리 수준에선 PHANTOM-READ 부정합이 발생하지 않는데 어떻게 이게 가능 할까요?

• InnoDB 특성 상 넥스트 키 락을 통해 막을 수 있다고 하는데 솔직히 잘 이해가 되지 않는다
• SELECT… FOR UPDATE 쿼리 같은 경우에는 언두 레코드에 잠금을 걸 수 없어 일관된 읽기가 풀리고 현재 레코드 값을 가져와서 PHANTOM-READ 부정합이 발생된다

---

11. 네임드 락(Named Lock)에 대해 설명 해 주세요

• 네임드 락은 테이블이나 레코드 등 데이터베이스의 객체가 대상이 아닌, 문자열을 통해 잠금을 거는 락입니다
• 주로 사용되지는 않지만 배치 프로그램에서는 유용하게 사용될 수 있습니다
• 많은 양의 데이터를 집어 넣을 때 데드락이 발생되는 경우가 많은데 이 때 동일한 데이터나 비슷한 프로그램 부류끼리 묶어서 네임드락을 사용하면 효과적으로 데드락을 회피할 수 있습니다.

[giibeom]

스터디 후 잔여 궁금증 (공통)

1. PK 또는 유니크 인덱스에 의한 변경 작업은 딱 레코드 그 자체에 대해서만 락을 거는지?
2. SELECT .... FROM UPDATE 할때 "현재" 레코드의 값을 가져오는건지?

Reference

• https://dev.mysql.com/doc/refman/8.0/en/innodb-next-key-locking.html
• https://dev.mysql.com/doc/refman/8.0/en/glossary.html#consistent_read
• https://medium.com/daangn/mysql-gap-lock-%EB%8B%A4%EC%8B%9C%EB%B3%B4%EA%B8%B0-7f47ea3f68bc
• https://medium.com/@bb8s/design-distributed-lock-with-mysql-9bc28ac59629