PostgreSQL 장애 대응 · 살아 있는 데이터베이스를 읽는다 · 퀴즈
퀴즈: 살아 있는 데이터베이스 읽기
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
막힌 세션의 `pg_blocking_pids` 가 가리키는 pid 를 끊었는데 상황이 그대로다. 가장 그럴듯한 이유는?
- 끊은 pid 도 자기가 막혀 있던 세션이라 사슬의 끝이 따로 있다
- pg_terminate_backend 는 잠금을 즉시 놓아 주지 않는다
- 잠금이 행이 아니라 표 전체에 걸려 있어 재시작이 필요하다
- 통계 수집기가 갱신되기 전이라 옛 값을 보고 있다
요청이 응답하지 않는데 느린 쿼리 목록이 비어 있다. 가장 먼저 볼 것은?
- 지난 한 시간의 평균 응답 시간 추이 그래프
- 체크포인트 주기와 WAL 생성량
- 가장 오래된 트랜잭션의 나이와 idle in transaction 세션
- 공유 버퍼 적중률과 디스크 읽기 대기
한 세션의 `wait_event` 가 `transactionid`, 다른 세션은 `tuple` 이다. 이 차이가 뜻하는 것은?
- 앞은 행 잠금이고 뒤는 표 잠금이라 잠금의 범위가 다르다
- 앞은 잠금을 쥔 트랜잭션을 직접, 뒤는 같은 행 대기 줄의 앞사람을 기다린다
- 앞은 읽기 잠금이고 뒤는 쓰기 잠금이라 충돌 조건이 다르다
- 앞은 교착 검사 전이고 뒤는 교착 검사를 이미 통과한 상태다
`lock_timeout` 이 0(기본값)인 서비스에서 한 행에 요청이 몰릴 때 가장 먼저 바닥나는 것은?
- 데이터베이스 서버의 CPU
- 공유 버퍼와 작업 메모리
- WAL 을 쌓아 두는 디스크 공간
- 애플리케이션의 커넥션 풀
커넥션이 꽉 찼을 때 `max_connections` 를 올리는 것이 첫 수가 아닌 이유는?
- 모자란 게 아니라 반납이 안 되는 것이라 묶이는 커넥션의 상한만 올라간다
- 이 설정은 재시작해야 반영되므로 장애 중에 바꿀 수 없다
- 슈퍼유저용 예비 슬롯이 함께 줄어 관리 접속이 막힌다
- 커넥션 수가 늘면 잠금 대기가 교착으로 바뀌기 때문이다
마이그레이션에 `lock_timeout` 을 반드시 거는 이유는?
- DDL 은 롤백할 수 없어서 중간에 끊을 방법이 그것뿐이라서
- 잠금을 오래 쥐면 WAL 이 재활용되지 않아 디스크가 차기 때문
- ACCESS EXCLUSIVE 대기가 그 뒤의 읽기까지 전부 줄 세우기 때문
- 대기 중인 DDL 이 교착으로 감지되지 않아 영원히 남기 때문