day-log

논리 복제(logical replication)를 실제 운영에서 굴려본 사람이라면 한 번쯤 겪는다. HA 구성 잘 짜놨고, 프라이머리가 죽어도 스탠바이로 넘어가는 건 문제 없다. 근데 넘어가고 나서 CDC 파이프라인이 조용히 멈춰있다. Debezium 로그를 보면 "replication slot does not exist". 이유는 단순하다 — 복제 슬롯은 프라이머리에만 있었고, 스탠바이가 승격되는 순간 그 슬롯의 커밋 위치 정보가 통째로 증발한 거다.PostgreSQL 17에서 failover slots가 정식으로 들어왔고, 18에서 1년치 버그 패치가 얹혀서 이제 프로덕션에서 쓸만해졌다. 이번 글은 그 세팅을 처음부터 끝까지 밟아보는 실무 가이드다. RDS를 쓰는 팀에게도 해당되는 이야기가 있어서 뒤..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. topologySpreadConstraints에서 whenUnsatisfiable: ScheduleAnyway로 설정해두고 "AZ 골고루 퍼지겠지" 안심하다가 뒤통수 맞기 딱 좋다.우리 팀에서도 이번 주에 비슷한 일이 있었다. 3-AZ EKS에 6개 replica를 배포하는데 특정 AZ에 4개가 몰려서 나머지 두 AZ는 각각 1개씩. 스펙에 maxSkew: 1, whenUnsatisfiable: ScheduleAnyway가 분명히 박혀 있는데도 그랬다.왜 이런 일이 생기나ScheduleAnyway는 이름 그대로 소프트 제약이다. 스케줄러가 최선을 다해서 스프레드를 지키려 하지만, 다른 스코어링(리소스 여유, 이미지 로컬리티, 노드 셀렉터 우선순위 등)이 ..

지난 화요일 새벽이었다. 4시 12분에 휴대폰이 부르르 울렸다. PagerDuty.vault-prod cluster: all nodes sealed침대에서 일어나면서 머릿속이 멍했다. 보통 vault가 sealed 상태로 돌아가는 일은 없다. unseal key는 사람이 들고 있지도 않다 — auto-unseal로 AWS KMS에 위임해놨으니까. 그런데 sealed라니. 노트북을 열면서 솔직히 멘탈이 좀 나갔다.첫 30분: 뭐가 죽었는지조차 몰랐다처음엔 vault 자체 이슈인 줄 알았다. 컨테이너가 OOM이라도 났나 싶어서 노드부터 확인했다. CPU도 메모리도 멀쩡했다. Pod도 다 running이었고. 그런데 vault status를 때려보면 매번 같은 응답이 돌아왔다.Sealed: trueTotal ..