THE NICOLE🌱

핵심 요약최근 데이터베이스 일일 점검을 자동화하는 프로젝트를 맡게 되면서, DBA가 매일 들여다보는 모니터링 지표들을 처음부터 정리하고 있습니다. 첫 글에서 MySQL, 두 번째 글에서 Oracle을 다뤘는데, 이번 PostgreSQL이 시리즈의 마지막입니다. PostgreSQL은 같은 관계형 데이터베이스이면서도 데이터를 관리하는 방식이 앞의 둘과 또 달라서, 지표 이름에도 다른 DB에는 없는 단어들이 보였습니다. Dead Tuple, VACUUM, Age, autovacuum 같은 말이 그렇습니다. 그래서 이번에도 하나씩 정리해 두기로 했습니다.이 글에서는 PostgreSQL(및 PostgreSQL on RDS)에서 자주 보는 지표들을 ① 무엇을 의미하는지 ② 평소 어느 정도 값이 정상인지(실제 관측 ..

핵심 요약DB 일일 점검 자동화 POC를 진행하면서 가장 먼저 막힌 부분은 알고리즘이 아니라 지표 그 자체였습니다. 저는 백엔드 개발자라 DBA가 매일 보는 지표(Active Session, Row Lock Waits, Redo, Vacuum 같은 것들)가 무엇을 뜻하는지, 어떤 값이 정상이고 어떤 값이 위험인지, 그리고 그 값이 이상하면 무엇을 들여다봐야 하는지를 몰랐습니다. 자동 점검 시스템을 만들려면 결국 이 지표들을 제가 이해하고 있어야 했습니다.이 글은 그 과정에서 정리한 내용입니다. DB 모니터링에서 자주 보는 지표를 9개 묶음(CPU·세션·연결·락·장기쿼리·쓰기·IO·메모리·스토리지)으로 나누고, 각 지표가 무엇을 의미하는지, 일상적인 비유로 어떻게 이해하면 되는지, Oracle·MySQL·..

핵심 요약한 대기업 제조사에서 DBA가 매일 아침 30분~1시간씩 손으로 하던 DB 점검을, AI가 자동 분석해 매일 오전 8시 HTML 메일로 보내주는 시스템을 2주 POC로 만들고 있습니다.대상은 AWS RDS 위의 Oracle·MySQL·PostgreSQL 3종. 데이터는 모니터링 솔루션(DPM)이 1분 단위로 집계한 시계열 지표입니다.전체는 main.py가 collector → detector → reporter → mailer 4개 모듈을 순서대로 실행하는 파이프라인으로 구성되며, 이번 글은 그 첫 단계인 데이터 수집(collector.py)을 다룹니다.collector의 핵심 설계 목표는 "나중에 데이터 출처가 엑셀에서 실제 API로 바뀌어도, 이 파일 하나만 고치면 되게" 격리하는 것입니다...

읽기는 멀쩡한데 쓰기만 전부 500으로 죽었다. 그것도 어제까지 잘 돌던 서비스가. 범인은 의외로 "SQL 로그 좀 예쁘게 보려고" 끼워 넣은 드라이버였다. PgBouncer 뒤에서 @Transactional 쓰기 요청만 골라 죽이던 이 장애를 어떻게 잡았는지 정리한다.핵심 요약증상: 조회(SELECT)는 정상, @Transactional 쓰기 요청만 전부 500 (CannotCreateTransactionException). 헬스체크도 DOWN.환경: 앱이 PostgreSQL에 직접 붙지 않고 PgBouncer(커넥션 풀러)를 경유. pool_mode = transaction.방아쇠: 누군가 JDBC 드라이버를 org.postgresql.Driver → log4jdbc(DriverSpy, SQL 로깅 ..