Weekly Diary #4
처음으로 개발 내용 작성
이전 회고록에 언급하였듯이 Postgres DB서버 Master -Standby 세팅 부분에 문제가 생겼었다.
디비는 Streaming으로 복제 중이고 Log Shipping 방식으로 WAL 파일을 Standby 서버에 백업용으로 적재 중이었다.
최초 세팅 후 Standby 디비의 Master 승격 테스트까지 완료하고 뿌듯한 마음으로 터미널을 종료했다. 그리고 해당 부분은 기억 속 저 뒷 구석에 묻혔다.
그 후 한 달 하고 며칠 뒤 디비 솔루션 작업 때문에 Standby 서버에 접속해서 디비를 확인하던 중...
이게 무슨 일인가....
Standby 서버의 디비가 죽어있는 것이었다....
에러 로그를 확인해보니, 파일 시스템의 용량이 모자라 실행을 할 수가 없다고 나왔다.
영문을 알 수가 없는 일이었다. 아직 일반 유저를 받기 전이었기도 하고 해당 서버의 용량은 1TB였기 때문이다.
그래서 용량을 확인하기 위해 $ df -h 명령어를 실행해보니 용량은 넉넉했다.
그런데 유독 한 파일 시스템의 용량이 꽉 찬 것을 확인하였다.
맞다. 보통 가이드 문서대로 설치할 때의 그 기본 경로가 속한 파일 시스템이었다. 그러나 해당 서버의 대부분의 용량(약 900gb)은 폴더로는 /home 아래이자 파일 시스템 명으로는 /dev/sda2 가 차지하고 있었다.
혹시나 해서 Master 디비 서버도 확인해봤는데, 혹시나가 역시나였다.
다 기본 경로에 설치를 해놓아서 대용량이 남아돌고 있었다.
여지없이 내 실수였다. 그래도 다행인 건 아직 실제 유저가 없고 개발 테스트용 유저들만 있었다. 그래서 나는 클라이언트팀이 작업하지 않는 저녁 시간에 회사에 남아 (해당 가상 서버 접속은 회사의 특정 IP로만 접속이 가능한 상황이었다) 이전의 디비들은 날리고 대용량의 경로에 Master - Standby를 구축했다.
그런데 아직 근원적인 이유는 해결하지 못한 상태였다. 왜냐면 레플리케이션을 스트리밍으로 하는 중이었는데 Master 디비는 살아있었기 때문이다. 그때 생각났던 게 백업용으로 쌓고 있던 WAL 파일들의 존재 여부였다.
master 디비의 환경 설정을 살펴보니
archive_timeout = 30이었고
WAL 파일의 사이즈는 기본적으로 16mb이었다.
그 말인즉슨 WAL 파일이 Log shipping 방식으로 Standby 서버에 30초마다 쌓인다는 뜻이다.
그리고 standby 서버에 쌓이고 있는 WAL 파일을 확인해보니 일치했다.
계산해보니 1분에 32mb, 1시간에 1.92gb, 1일에 약 46gb였다.
용량이 모자라 디비가 안 터질 수가 없는 상황이었다.
archive_timeout 을 어느 정도 늘리면 상황은 나아지지만 결국에는 WAL파일을 정리해야 했다.
그래서 내린 결론은 Master 디비를 헬스체크하며 필요시 WAL파일을 삭제하면 되겠다 였다. 그래서 curl로 Master 디비를 체크해서 디비가 살아있고, WAL파일이 저장된 파일 스토리지의 용량이 60%가 넘는다면 해당 파일들을 날리는 shell script를 작성하고 해당 script를 crontab으로 매분 실행시켰다.
그리고 만약 헬스체크 결과 Master 디비가 죽어있다면 Standby 디비의 recovery.conf의 옵션 중 하나인 trigger_file에 등록된 경로에 파일을 생성해서 standby 서버를 master 서버로 승격시킨다.
생애 처음으로 자동화하는 스크립트를 작성하여 서버에 적용시키는 데에 성공하니 기분이 좋았다.
스크립트에 추가되어야 할 부분을 더 생각해봐야겠다.
참조: https://medium.com/qodot/postgresql-replication-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-dfd481c4fb04 (master-standby 세팅)
https://www.bmc.com/blogs/top-dba-shell-scripts-for-monitoring-the-database/ (스크립트 작성)
