스키마 변경이 든 핫픽스는 DB 인프라와 일정 협의, 새 컬럼이 없어도 동작하는 코드를 먼저 배포.
인프라팀 할 일
잠금 대기 한도를 짧게 걸고 실패하면 다시 시도, 긴 트랜잭션이 없을 때 실행, 온라인 변경 도구 사용, 큰 테이블은 점검 시간에.
그래프에서는
어느 순간부터 계단처럼 올라감 · 잠금 대기 세션 수, 그 테이블의 쿼리 지연
확인할 곳
MySQL은 SHOW PROCESSLIST에서 State가 Waiting for table metadata lock인 세션을 세고, sys.schema_table_lock_waits로 막고 있는 세션(blocking_pid)을 찾음. PostgreSQL은 pg_locks에서 granted가 false인 요청과 AccessExclusiveLock을 보고, pg_blocking_pids()로 막고 있는 세션을 찾음
이러면 맞음
스키마 변경을 시작한 시각부터 그 테이블을 쓰는 모든 쿼리가 잠금 대기로 쌓이고, 맨 앞에 끝나지 않은 트랜잭션이나 스키마 변경 문장이 있음
이러면 아님
대기가 특정 행에만 몰리고 같은 테이블의 다른 행은 잘 처리되면 핫 로우(db-hot-row)
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
MySQL은 스키마를 바꿀 때 메타데이터 잠금을, PostgreSQL은 가장 강한 테이블 잠금을 잠깐 잡습니다. 변경 자체는 순식간이어도, 앞에 끝나지 않은 트랜잭션이 하나 있으면 그 뒤로 모든 요청이 대기합니다.