PostgreSQL 주니어 트러블슈팅 면접
새 면접Q. 애플리케이션에서 PostgreSQL 데이터베이스에 연결을 시도하는데 'FATAL: remaining connection slots are reserved for non-replication superuser connections' 에러가 발생했습니다. 이 에러의 원인과 해결 방법, 그리고 재발 방지를 위한 조치를 설명해주세요.
PostgreSQL의 최대 연결 수 설정과 현재 활성 연결 수를 확인해보세요.
이 에러는 PostgreSQL의 max_connections 설정값에 도달하여 더 이상 새로운 연결을 받을 수 없을 때 발생합니다. postgresql.conf에서 max_connections 값을 확인하고, pg_stat_activity 뷰를 조회하여 현재 활성 연결 수와 유휴 연결을 파악해야 합니다. 단기적으로는 불필요한 연결을 종료하거나 max_connections 값을 증가시킬 수 있습니다. 장기적으로는 애플리케이션에서 Connection Pool을 적절히 설정하여 연결을 재사용하고, 사용 후 반드시 연결을 반환하도록 코드를 수정해야 합니다. 또한 연결 누수가 발생하지 않도록 try-finally 블록이나 컨텍스트 매니저를 사용하여 연결 관리를 안전하게 처리해야 합니다.
- • max_connections 설정값 도달이 원인
- • pg_stat_activity로 현재 연결 상태 확인
- • Connection Pool 설정으로 연결 재사용
- • 연결 누수 방지를 위한 안전한 연결 관리
트래픽이 급증하는 이벤트 기간에 연결 풀 설정이 부적절하여 데이터베이스 연결 장애가 발생하는 상황에서 활용됩니다.
Connection Pool의 적정 크기는 어떻게 결정하나요? pool size와 max overflow를 설정할 때 고려해야 할 요소는 무엇인가요?
Q. 운영 중인 서비스에서 'ERROR: deadlock detected' 에러가 간헐적으로 발생하고 있습니다. 데드락의 원인을 파악하는 방법과 PostgreSQL 로그에서 확인해야 할 정보, 그리고 데드락을 해결하고 재발을 방지하기 위한 전략을 설명해주세요.
여러 트랜잭션이 서로 다른 순서로 리소스를 잠그려 할 때 발생할 수 있습니다.
데드락은 두 개 이상의 트랜잭션이 서로가 보유한 락을 기다리면서 무한 대기 상태에 빠지는 현상입니다. PostgreSQL 로그에서 DETAIL 부분을 확인하면 데드락에 관련된 프로세스 ID, 쿼리, 락 타입을 확인할 수 있습니다. pg_locks 뷰와 pg_stat_activity를 조인하여 현재 락 상태를 실시간으로 모니터링할 수 있습니다. 해결 방법으로는 모든 트랜잭션에서 동일한 순서로 테이블이나 행에 접근하도록 코드를 수정하고, 트랜잭션의 범위를 최소화하여 락 보유 시간을 줄여야 합니다. 또한 SELECT FOR UPDATE를 사용할 때는 NOWAIT 옵션을 고려하여 즉시 실패하도록 하거나, 애플리케이션 레벨에서 재시도 로직을 구현할 수 있습니다. 배치 작업이나 대량 업데이트는 작은 단위로 나누어 처리하는 것이 좋습니다.
- • PostgreSQL 로그의 DETAIL 섹션에서 데드락 정보 확인
- • 모든 트랜잭션에서 동일한 순서로 리소스 접근
- • 트랜잭션 범위 최소화로 락 보유 시간 단축
- • 재시도 로직 구현 또는 NOWAIT 옵션 활용
주문 처리와 재고 차감이 동시에 발생하는 커머스 시스템에서 여러 주문이 동시에 같은 상품을 업데이트할 때 데드락이 발생하는 상황에서 활용됩니다.
FOR UPDATE와 FOR SHARE의 차이점은 무엇이며, 각각 어떤 상황에서 데드락을 유발할 수 있나요?
Q. 어제까지 정상적으로 동작하던 특정 쿼리가 오늘 갑자기 매우 느려졌습니다. 데이터양은 크게 변하지 않았고 스키마 변경도 없었습니다. 이런 상황에서 원인을 진단하는 단계별 절차와 각 단계에서 확인해야 할 사항, 그리고 가능한 원인과 해결 방법을 설명해주세요.
인덱스 통계 정보나 쿼리 플랜이 변경되었을 가능성을 고려해보세요.
먼저 EXPLAIN ANALYZE를 실행하여 현재 쿼리 실행 계획을 확인하고, 예상 행 수와 실제 행 수의 차이를 확인해야 합니다. 통계 정보가 오래되어 옵티마이저가 잘못된 실행 계획을 선택했을 가능성이 높으므로 ANALYZE 명령으로 테이블 통계를 갱신합니다. pg_stat_user_tables를 조회하여 마지막 VACUUM과 ANALYZE 시간을 확인하고, autovacuum이 제대로 동작하는지 점검합니다. 인덱스가 bloat 상태인지 확인하고 필요하면 REINDEX를 실행합니다. pg_stat_activity로 동시 실행 중인 쿼리나 락 대기 상황을 확인하고, 시스템 리소스 사용률도 점검합니다. 문제가 지속되면 쿼리를 힌트나 명시적 JOIN 순서 조정으로 최적화하거나, 필요한 인덱스를 추가로 생성할 수 있습니다.
- • EXPLAIN ANALYZE로 실행 계획과 예상/실제 행 수 비교
- • ANALYZE 명령으로 통계 정보 갱신
- • autovacuum 동작 여부와 인덱스 bloat 확인
- • 동시 실행 쿼리와 시스템 리소스 점검
대량의 INSERT/UPDATE/DELETE 작업 후 통계 정보가 부정확해져서 기존에 잘 동작하던 쿼리의 성능이 갑자기 저하되는 상황에서 활용됩니다.
autovacuum의 동작 원리와 autovacuum_naptime, autovacuum_vacuum_threshold 같은 설정값의 의미를 설명해주세요.
Q. 운영 중인 PostgreSQL 서버에서 디스크 용량 부족 알람이 발생했습니다. pg_dump 백업 파일과 실제 데이터베이스 크기를 비교했을 때 실제 사용 중인 디스크가 훨씬 더 큽니다. 이런 상황에서 디스크 공간을 차지하는 주요 원인을 파악하는 방법과 공간을 확보하는 방법을 설명해주세요.
WAL 파일, 임시 파일, 그리고 테이블 bloat를 확인해보세요.
먼저 pg_database_size와 pg_table_size 함수로 각 데이터베이스와 테이블의 실제 크기를 확인합니다. pg_stat_user_tables의 n_dead_tup 컬럼을 조회하여 삭제되었지만 아직 정리되지 않은 dead tuple 수를 확인하고, VACUUM FULL로 공간을 회수할 수 있습니다. pg_wal 디렉토리의 WAL 파일이 과도하게 쌓여있는지 확인하고, archive_command 설정이 제대로 동작하는지 점검합니다. pg_stat_database의 temp_files와 temp_bytes를 확인하여 임시 파일 사용량을 파악하고, work_mem 설정이 적절한지 검토합니다. 인덱스 bloat도 주요 원인이 될 수 있으므로 pgstattuple 확장을 사용하여 bloat 비율을 확인하고 REINDEX로 재구성합니다. 로그 파일도 정기적으로 로테이션되는지 확인하고, 불필요한 백업 파일이나 덤프 파일을 정리합니다.
- • pg_database_size, pg_table_size로 실제 크기 확인
- • dead tuple 확인 후 VACUUM FULL로 공간 회수
- • WAL 파일 누적과 archive_command 동작 점검
- • 임시 파일, 인덱스 bloat, 로그 파일 확인
대량 삭제 작업 후 디스크 공간이 회수되지 않아 디스크가 가득 차는 상황이나, WAL 아카이빙 실패로 WAL 파일이 계속 쌓이는 상황에서 활용됩니다.
VACUUM과 VACUUM FULL의 차이점은 무엇이며, VACUUM FULL을 운영 중에 실행할 때 주의해야 할 점은 무엇인가요?
Q. 마스터-슬레이브 구조의 PostgreSQL 복제 환경에서 애플리케이션이 슬레이브에서 읽은 데이터가 마스터와 일치하지 않는 문제가 발생했습니다. 사용자가 방금 등록한 데이터를 조회했는데 보이지 않는다는 문의가 들어왔습니다. 이런 상황에서 복제 지연을 확인하는 방법과 원인을 파악하는 절차, 그리고 단기적 대응과 장기적 해결 방안을 설명해주세요.
마스터와 슬레이브 간의 복제 지연(replication lag)을 측정해보세요.
먼저 슬레이브에서 pg_stat_replication 뷰를 조회하여 replay_lag, write_lag, flush_lag 값을 확인하고 복제 지연 정도를 파악합니다. pg_last_wal_receive_lsn()과 pg_last_wal_replay_lsn()을 비교하여 수신은 되었지만 아직 적용되지 않은 WAL의 양을 확인할 수 있습니다. 복제 지연의 원인은 슬레이브의 하드웨어 성능 부족, 네트워크 지연, 마스터의 과도한 쓰기 부하, 슬레이브에서 실행 중인 긴 쿼리가 복제를 블로킹하는 경우 등이 있습니다. 단기적으로는 중요한 읽기 쿼리를 마스터로 라우팅하거나, 애플리케이션에서 쓰기 후 즉시 읽기가 필요한 경우 명시적으로 마스터에서 읽도록 처리합니다. 장기적으로는 슬레이브 서버의 스펙을 업그레이드하거나, hot_standby_feedback을 활성화하여 복제 충돌을 줄이고, max_standby_streaming_delay 설정을 조정하거나, 읽기 부하를 여러 슬레이브로 분산시킵니다.
- • pg_stat_replication으로 replay_lag 등 복제 지연 확인
- • 슬레이브 성능, 네트워크, 긴 쿼리 등 원인 파악
- • 단기적으로 중요 읽기를 마스터로 라우팅
- • 장기적으로 hot_standby_feedback, 서버 스펙 업그레이드 고려
읽기 부하 분산을 위해 슬레이브를 사용하는 서비스에서 사용자가 등록한 게시글이 목록에 즉시 보이지 않아 문의가 들어오는 상황에서 활용됩니다.
동기 복제(synchronous replication)와 비동기 복제(asynchronous replication)의 차이점과 각각의 장단점을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!