Kubernetes 위의 PostgreSQL HA(Patroni 계열)에서 lease 갱신 실패로 standby 가 승격됐을 때, standby 로그만으로 무엇을 읽어낼 수 있고 무엇을 더 봐야 하는지 정리한다. 승격된 쪽 로그만 보고 "lease 실패가 원인" 이라고 결론 내리면 진짜 원인을 놓친다.
server closed the connection unexpectedly) standby 가 곧 재접속했다.could not send data to client: Broken pipe 가 여럿 남았다. 이미 불안정했다는 정황이다.received promote request(04:34) 사이 20 분 간극은 재시도·타임아웃 임계치나 fencing 대기일 수 있어 따로 확인한다.| 대상 | 볼 것 |
|---|---|
| 구 primary 의 PostgreSQL 로그 | PANIC, could not write/fsync 오류, checkpoint hang, disk full, terminating connection |
| 해당 Pod·노드 | dmesg, kubelet 로그의 OOMKill 또는 NotReady — 이것이면 lease 실패와 WAL 정체가 한 번에 설명된다 |
| HA 오케스트레이터(Patroni 등)와 kube-controller-manager | leader lease 가 언제 만료·해제됐는지 |