LabHub

스키마 변경 — 배포가 서비스를 멈추지 않게 · 잠금과 배포 · 퀴즈

마이그레이션 확인

LabHub 에서 이어서 보기

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 요즘 디스크가 충분히 빨라져 전체 재작성이 금방 끝나서
    2. PostgreSQL 11 부터 기본값을 메타데이터에만 적어 둔다
    3. 여러 코어로 병렬 처리해서
    4. 페이지를 압축해 쓰기 때문
  2. 그런데도 마이그레이션이 위험한 이유는?

    1. 변경 작업 자체가 오래 걸려서
    2. 디스크 공간을 많이 잡아먹어서
    3. 잠금을 기다리는 동안 뒤의 모든 쿼리가 같이 줄을 서서
    4. 복제 지연이 커지기 때문
  3. 그 상황에서 DB 지표는?

    1. CPU 가 100%
    2. 디스크가 꽉 참
    3. 메모리 부족
    4. 멀쩡하다 — 쿼리 하나하나는 다 빠르다
  4. `lock_timeout` 과 `statement_timeout` 의 차이는?

    1. 둘은 사실상 같은 설정이다
    2. 앞의 기본값이 더 길다
    3. 앞은 읽기 질의에만 걸린다
    4. 앞은 기다리는 시간, 뒤는 실행 시간 제한
  5. `CREATE INDEX` 가 막는 것은?

    1. 쓰기 (INSERT/UPDATE/DELETE)
    2. 읽기(SELECT) 를 막는다
    3. 읽기와 쓰기를 모두 막는다
    4. 아무것도 막지 않는다
  6. `CREATE INDEX CONCURRENTLY` 의 제약은?

    1. 트랜잭션 안에서 못 쓰고, 실패하면 못 쓰는 인덱스가 남는다
    2. 특별한 제약이 없다
    3. 만들어진 인덱스가 일반 방식보다 더 커진다
    4. 인덱스 정확도가 떨어진다
  7. 실패한 CONCURRENTLY 인덱스를 찾는 법은?

    1. 서버 로그에서 실패를 찾는다
    2. EXPLAIN 으로 사용 여부를 본다
    3. pg_index 에서 not indisvalid 를 찾는다
    4. 서버를 재시작하면 정리된다
  8. 컬럼을 지울 때 배포를 나누는 이유는?

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