벼락치기 개발공부

제가 서비스를 운영하면서 직접 겪은 . . .primary 1대 + standby 3대 구성부터 upstream 변경, 그리고 장애 시 promote까지단순 이론 말고 실제 삽질하면서 경험한 내용을 정리해서 작성해보았습니다! 1️⃣ 4노드 HA 구성목표 구조기존 프로젝트에서는 primary 와 standby 로 구성된 ha 상태의 DB 서비스를 운영하고 있었습니다.이해를 돕기 위해 각각의 DB 01, 02, 03, 04 같이 순번을 붙혀 설명하겠습니다.db01 (primary) └─ db02 (standby) 그러던 중 DB 서버의 OS 업그래이드를 하게 되었습니다.In-place 업그레이드를 진행하면 라이브러리나 DB extension 이 깨질 수 있기 때문에DB를 먼저 Standby 로 복제를 떠서..

운영 환경에서 대규모 마이그레이션 작업을 진행하던 중 예상하지 못한 상황을 경험했습니다. DB 전체 스토리지는 약 7TB였고 실제 데이터는 약 5.6TB 수준이었습니다.표면적으로 보면 여유가 있는 상황이었지만, 어느 순간 WAL 사용량이 급격히 증가하여 pg_wal 영역이 1.8TB까지 커지는 상태가 발생했습니다. 확인해보니 archive storage 3TB가 이미 100% 가득 찬 상태였고,그 영향으로 WAL이 정상적으로 정리되지 못하고 계속 쌓이고 있었습니다. DB는 즉시 다운되지는 않았지만조금만 더 진행되었다면 실제 서비스 쓰기 장애로 이어질 수 있는 매우 위험한 상황이었습니다.이번 글에서는 이 상황이 왜 발생했는지, 실제로 어떤 위험이 있었는지, 그리고 어떻게 해결했는지까지 운영 경험 기반으로 ..

데이터베이스를 사용하다 보면 자연스럽게 이런 궁금증이 생깁니다.“INSERT나 UPDATE를 하면 데이터는 바로 디스크에 저장되는 걸까?” 하는 질문인데요. 실제로 대부분의 RDBMS는 이런 방식으로 동작하지 않습니다.성능과 안정성을 동시에 확보하기 위해 데이터 변경은 먼저 메모리에서 처리하고, 변경 사실은 로그에 기록한 뒤 실제 디스크 반영은 이후 시점에 수행하는 구조를 사용합니다. 이번에 이러한 구조를 가진 RDBMS 의 디스크 활용법에 대해서 알아보겠습니다! 🚀 RDBMS는 데이터를 바로 디스크에 저장하지 않는다? Oracle, MySQL(InnoDB), PostgreSQL 같은 주요 RDBMS들은구현 방식이나 내부 명칭은 조금씩 다르지만이러한 메모리 기반 처리 + 로그 기반 안정성 확보 구조를..