Migration Check

기본값 있는 컬럼 추가가 이제 빠른 이유는?

• 요즘 디스크가 충분히 빨라져 전체 재작성이 금방 끝나서
• PostgreSQL 11 부터 기본값을 메타데이터에만 적어 둔다
• 여러 코어로 병렬 처리해서
• 페이지를 압축해 쓰기 때문

그런데도 마이그레이션이 위험한 이유는?

• 변경 작업 자체가 오래 걸려서
• 디스크 공간을 많이 잡아먹어서
• 잠금을 기다리는 동안 뒤의 모든 쿼리가 같이 줄을 서서
• 복제 지연이 커지기 때문

그 상황에서 DB 지표는?

• CPU 가 100%
• 디스크가 꽉 참
• 메모리 부족
• 멀쩡하다 — 쿼리 하나하나는 다 빠르다

lock_timeout 과 statement_timeout 의 차이는?

• 둘은 사실상 같은 설정이다
• 앞의 기본값이 더 길다
• 앞은 읽기 질의에만 걸린다
• 앞은 기다리는 시간, 뒤는 실행 시간 제한

CREATE INDEX 가 막는 것은?

• 쓰기 (INSERT/UPDATE/DELETE)
• 읽기(SELECT) 를 막는다
• 읽기와 쓰기를 모두 막는다
• 아무것도 막지 않는다

CREATE INDEX CONCURRENTLY 의 제약은?

• 트랜잭션 안에서 못 쓰고, 실패하면 못 쓰는 인덱스가 남는다
• 특별한 제약이 없다
• 만들어진 인덱스가 일반 방식보다 더 커진다
• 인덱스 정확도가 떨어진다

실패한 CONCURRENTLY 인덱스를 찾는 법은?

• 서버 로그에서 실패를 찾는다
• EXPLAIN 으로 사용 여부를 본다
• pg_index 에서 not indisvalid 를 찾는다
• 서버를 재시작하면 정리된다

컬럼을 지울 때 배포를 나누는 이유는?

• 한 번에 지우면 작업이 오래 걸리기 때문
• 아직 그 컬럼을 읽는 코드가 도는 중이면 오류가 나서
• 긴 잠금이 걸리기 때문
• 복제가 밀리기 때문