VACUUM - vacuum 실패

• VACUUM에 대한 블로그 글을 읽고 정리한 내용입니다. 읽은 블로그는 아래와 같습니다.
  • PostgreSQL Vacuum에 대한 거의 모든 것
  • 19.11. 클라이언트 연결 기본값
• 틀린 내용이 존재할 수 있습니다.

vacuum 실패

Long transaction이 수행되는 경우

• AutoVacuum이 수행되고 있는 시점에 이미 오래 수행중인 쿼리를 Long transaction이라고 할 수 있습니다.
  • 수행시간이 무지하게 긴 쿼리라고 생각하면될거 같습니다.
• Long transaction이 수행 중에 참조되는 tuple 들로 인해 dead tuple이 정리가 되지 않는 경우가 있습니다.
• 이러한 경우를 피하기 위해 Long transaction과 commit이 안된 transaction에 대한 모니터링이 필요합니다.
• statement_timeout와 idle_in_transaction_session_timeout 같은 파라미터로 쿼리 혹은 트랜잭션이 너무 길게 실행되지 않도록 할 수 있습니다.
  • statement_timeout

    명령이 클라이언트에서 서버로 도착한 때부터 걸린 시간이 지정된 밀리초를 초과한 문을 중단한다 ... 모든 세션에 영향을 줄 수 있으므로 postgresql.conf에서 statement_timeout을 설정하는 것은 권장하지 않는다.
    19.11. 클라이언트 연결 기본값

  • idle_in_transaction_session_timeout

    Terminate any session with an open transaction that has been idle for longer than the specified duration in milliseconds ...
    19.11. 클라이언트 연결 기본값

  • ※ postgresql.conf은 메인 서버 환경 설정 파일로 해당 파일에 파라미터 값을 설정하면 해당 내용이 전역으로 설정되는 것으로 보입니다.

미사용의 버려진 replication slot이 있을때

• replication architecture인 경우 일어나는 실패로 보입니다.
• standby 서버에 복제 지연이 있거나 standby server가 다운되는 경우, replication slot은 복제에 필요한 데이터를 계속 담아두게 되고, 이처럼 남겨진 replication slot이 갖고 있는 데이터가 Dead Tuple이 정리되는 것을 방해하게 됩니다.

hot_standby_feedback = ON 인 경우

• replication architecture인 경우 일어나는 실패입니다.
• Master에서는 Dead Tuple로 확인되어 vacuum이 정리한 Tuple이 Replica server에서는 복제 지연이나 Long transaction 수행으로 인해 해당 데이터를 필요로 할 수 있습니다. 이런 경우 replication confilct가 발생하기 때문에 hot_standby_feedback = ON 설정을 통해 Replica 서버에서 수행한 쿼리와 가장 오래된 트랜잭션 정보를 Master로 주게 되고, 그때까지 Master는 해당 Dead Tuple을 정리할 수 없게 됩니다.