소니 스토리 (Sony Story)

PostgreSQL 고가용성 & 모니터링 + AI 운영 자동화 (시리즈 완결)테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19c드디어 이 시리즈의 마지막 편입니다. 15편에 걸쳐 Oracle DBA 관점에서 PostgreSQL을 정리해왔는데, 그 대미를 장식할 주제는 고가용성(HA), 모니터링, 그리고 AI를 활용한 운영 자동화입니다. 운영의 궁극적 목표는 하나입니다. "서비스가 멈추지 않게 하는 것." Oracle에서 Data Guard, RAC로 이걸 달성했다면, PostgreSQL은 스트리밍 복제를 기반으로 합니다. 이번 편에서 그 방법과, 15년 경험에 AI를 더하는 법까지 정리합니다. 이번 편은 운영 시리즈의 마지막이자 PostgreSQL 시리즈 전체의 완결..

PostgreSQL 물리 백업 & PITR 완벽 정리 - 증분 백업까지 (Oracle RMAN 대응)테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19c"실수로 운영 테이블을 DROP 했어요. 오후 3시였는데, 2시 59분으로 되돌릴 수 있나요?"Oracle DBA라면 "RMAN으로 PITR 하면 되지"라고 답할 겁니다. PostgreSQL도 됩니다. 바로 이번 편의 주제, 물리 백업과 PITR(시점 복구) 입니다.13편의 논리 백업(pg_dump)이 "유연한 백업"이었다면, 이번 물리 백업은 "대용량 운영 DB의 진짜 백업" 입니다. 그리고 본인이 요청하신 증분 백업도 드디어 나옵니다. 마침 PostgreSQL 17에서 증분 백업이 새로 추가돼서 시의적절해요.이번 편..

새벽 3시에 걸려오는 전화의 원인들 - PostgreSQL 운영 장애 TOP 10 (그림 3개)테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19cDBA에게 가장 무서운 건 새벽 3시의 전화입니다. "DB가 이상해요", "서비스가 느려요", "접속이 안 돼요."Oracle이든 PostgreSQL이든 장애는 옵니다. 그런데 PostgreSQL은 Oracle과 자주 터지는 지점이 조금 다릅니다. MVCC, autovacuum, 연결 모델 같은 PostgreSQL 특유의 구조에서 오는 문제들이 있거든요.이번 편은 운영 시리즈의 세 번째 글입니다. 15년 넘게 운영하며 만난, 그리고 PostgreSQL 커뮤니티가 공통으로 꼽는 운영 장애 TOP 10을 정리했습니다. 각 문제의..

autovacuum 방치했다가 DB 멈춘 썰 (PostgreSQL VACUUM 완벽 정리, 그림 5개)테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19cOracle DBA 시절엔 신경 쓸 필요 없던 게 PostgreSQL엔 하나 있습니다. 바로 VACUUM입니다.처음엔 저도 무시했습니다. "자동으로 돈다며? 그럼 놔두면 되지." 그런데 어느 날 디스크가 이유 없이 계속 차오르고, 잘 돌던 쿼리가 느려지기 시작했습니다. 알고 보니 autovacuum이 제대로 안 돌고 있었고, dead tuple이 산더미처럼 쌓여 있었습니다. 최악의 경우엔 트랜잭션 ID wraparound로 DB가 통째로 멈출 수도 있다는 걸 나중에 알고 식은땀을 흘렸습니다.이번 편은 운영 시리즈의 두..

Oracle 사용자가 PostgreSQL 보고 배 아파하는 기능 6가지 (PostgreSQL 킬러 기능 총정리)테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19c지금까지 이 시리즈는 "Oracle과 뭐가 다른가"를 주로 다뤘습니다. 대부분 "Oracle에선 이랬는데 PostgreSQL에선 저렇다" 식이었죠.이번 편은 다릅니다. "이건 Oracle에도 있었으면 좋겠다" 싶은, PostgreSQL만의 킬러 기능들입니다. 솔직히 저는 이 기능들을 보면서 Oracle 시절이 살짝 억울했습니다. "이걸 그동안 복잡하게 돌아갔던 거야?"이번 편은 실무 시리즈의 하이라이트입니다. 실습으로 직접 확인하며 진행합니다.①JSONB - MongoDB를 대체하는 문서 저장소②배열 타입 -..