DB Age Full 로 인한 DB 사용 불가

 

이 페이지에서는 정기 Vacuum 미 관리 및 파티션 미적용 테이블에 대한 DB Age Full 로 인하여 발생한 사례를 다룬다.

이 페이지를 보기 전, Age 및 Vacuum 개념에 대해서 확인 해 두면 좋다.

 

2021.04.16 - [PostgreSQL/아키텍처 및 내부 구조] - PostgreSQL / PPAS DB Age

2021.03.08 - [PostgreSQL/Vacuum] - Vacuum 목적 및 종류

 

 

발생 과정

 

실제 운영중인 서비스 중, PostgreSQL 내에 1.3 TB 크기의 테이블이 있는 데이터베이스가 있었다. 지속적으로 트랜잭션이 들어오는 대용량 테이블 이었기에 지속적인 관리가 필요한 테이블이었다. 

 

위의 다른 페이지에서도 언급되었듯이 로그내에 할당 트랜잭션이 얼마 남지 않으면 로그 파일 내에 아래의 로그가 기록 되기 시작한다.

 

 

이를 해결 하기 위해서는 두가지의 방법을 생각 해 볼 수 있었다.

 

- DB Age 가 압도적으로 높은 대용량 테이블만 Vacuum (다른 테이블은 autovacuum 으로 관리 가능 수준)

 

- 대용량 테이블을 파티션화

 

테이블 혹은 데이터베이스 용량이 대용량 일수록 Vacuum 수행 시간이 길어지고 Vacuum 수행 동안에 다른 트랜잭션들과 충돌 등이 일어나서 Vacuum 이 실패하거나 수행되더라도 보관중이던 트랜잭션 ID 회수가 제대로 되지 않음, 회수 id 량보다 배정하는 id 량이 더 많은 문제등이 발생하므로 보통은 두번째 방안으로 데이터를 분리 후, 파티션 테이블 단위로 지속 부분 Vacuum 을 수행해 가는 경우가 일반적으로 선택하는 방법이다.

 

그러나 실제 운영서비스에서는 이에 대한 서비스 영향도 및 작업 수행을 위한 작업 시간을 개발 및 서비스 운영 (AO) 부서와 미리 상의하여 마련을 하게 된다. (특히나 이런 대용량 데이터베이스나 테이블이 있을수록)

 

이 때는 이를 위한 상호간의 커뮤니케이션 및 협업이 원할하게 되지 않아 지속적으로 age 가 상승하는 상황이었고, 결국은 장애 발생날 아래의 error log 를 발생 시키며 DB가 트랜잭션을 받지않는 비정상 상태가 되었다.

 

 

해결 방안

 

위의 log 내용과 같이 PostgreSQL 에서는 Single Mode 라 하여 관리자유저만 DB 에 접속하게 하는 일종의 안전모드 같은 모드가 있다. 이를 통하여 외부 트랜잭션을 차단 후 Database Vacuum 을 수행하여 다른 트랜잭션과 충돌이 없이 Vacuum 만 진행되게 하여 트랜잭션 id 를 회수 하고 이를 통하여 문제를 해결 하였다.

 

그러나, 1.3T 테이블이외에 대용량 테이블이 여러개있는 Database 였으므로 시간이 매우 오래 걸렸었다.

 

느낀점

 

사실 이 장애는 예방이 가능한 장애였으나, 기술적으로 예방 방법을 알아도 다른 부서와의 커뮤니케이션이 잘 되지 않으면 언젠가는 문제가 발생하게 된다는 것을 깨닫게 해준 사례였다. 이를 통하여 흔히 주변에서 말하는 협엽과 커뮤니케이션이 왜 중요한지를 다시 한번 생각 해 보게 되었다.