스키마 변경 — 배포가 서비스를 멈추지 않게 · 잠금과 배포 · 퀴즈
마이그레이션 확인
문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
기본값 있는 컬럼 추가가 이제 빠른 이유는?
- 요즘 디스크가 충분히 빨라져 전체 재작성이 금방 끝나서
- PostgreSQL 11 부터 기본값을 메타데이터에만 적어 둔다
- 여러 코어로 병렬 처리해서
- 페이지를 압축해 쓰기 때문
그런데도 마이그레이션이 위험한 이유는?
- 변경 작업 자체가 오래 걸려서
- 디스크 공간을 많이 잡아먹어서
- 잠금을 기다리는 동안 뒤의 모든 쿼리가 같이 줄을 서서
- 복제 지연이 커지기 때문
그 상황에서 DB 지표는?
- CPU 가 100%
- 디스크가 꽉 참
- 메모리 부족
- 멀쩡하다 — 쿼리 하나하나는 다 빠르다
`lock_timeout` 과 `statement_timeout` 의 차이는?
- 둘은 사실상 같은 설정이다
- 앞의 기본값이 더 길다
- 앞은 읽기 질의에만 걸린다
- 앞은 기다리는 시간, 뒤는 실행 시간 제한
`CREATE INDEX` 가 막는 것은?
- 쓰기 (INSERT/UPDATE/DELETE)
- 읽기(SELECT) 를 막는다
- 읽기와 쓰기를 모두 막는다
- 아무것도 막지 않는다
`CREATE INDEX CONCURRENTLY` 의 제약은?
- 트랜잭션 안에서 못 쓰고, 실패하면 못 쓰는 인덱스가 남는다
- 특별한 제약이 없다
- 만들어진 인덱스가 일반 방식보다 더 커진다
- 인덱스 정확도가 떨어진다
실패한 CONCURRENTLY 인덱스를 찾는 법은?
- 서버 로그에서 실패를 찾는다
- EXPLAIN 으로 사용 여부를 본다
- pg_index 에서 not indisvalid 를 찾는다
- 서버를 재시작하면 정리된다
컬럼을 지울 때 배포를 나누는 이유는?
- 한 번에 지우면 작업이 오래 걸리기 때문
- 아직 그 컬럼을 읽는 코드가 도는 중이면 오류가 나서
- 긴 잠금이 걸리기 때문
- 복제가 밀리기 때문