# 무중단 Postgres 업그레이드

> Clean Markdown view of GeekNews topic #12325. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=12325](https://news.hada.io/topic?id=12325)
- GeekNews Markdown: [https://news.hada.io/topic/12325.md](https://news.hada.io/topic/12325.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2023-12-14T10:03:34+09:00
- Updated: 2023-12-14T10:03:34+09:00
- Original source: [knock.app](https://knock.app/blog/zero-downtime-postgres-upgrades)
- Points: 2
- Comments: 1

## Topic Body

### Postgres 업그레이드를 위한 준비

- **리스크 평가**: 업그레이드 과정에서 발생할 수 있는 리스크 목록 작성 및 중요도에 따른 정렬.
- **리스크 해결 방안 모색**: 리스크를 완전히 제거하거나 시간에 걸쳐 분산시킬 수 있는 해결책 고려.
- **리스크 목록 업데이트**: 프로젝트 진행 중 새로운 리스크 발견 시 목록 갱신.

### 모니터링 및 메트릭스에 대하여

- **시스템 모니터링**: 데이터베이스와 시스템의 건강을 모니터링하기 위한 철저한 도구 사용.
- **핵심 메트릭스 관찰**: 트랜잭션 ID, CPU 사용량, 대기 세션, 쿼리 지연 시간, API 응답 지연 등 주요 메트릭스 모니터링.

### Postgres 업그레이드 옵션

##### 현장 업그레이드 (제로 다운타임 업그레이드에는 부적합)

- **현장 업그레이드의 한계**: AWS RDS에서 실행 시 데이터베이스 재부팅 필요, 데이터 양에 따라 시간 소요.

##### 복제 기반 업그레이드

- **복제 기반 업그레이드 선택**: 점진적인 마이그레이션 단계, 실제 워크로드와 데이터로 새 데이터베이스 테스트, 업그레이드 제어력 확보.
- **소스 및 대상 데이터베이스 설정**: 복제 슬롯 설정, `wal_level`을 `logical`로 설정.

### 테이블 복제 방법 선택

##### "작은" 테이블 복제

- **작은 테이블 복제**: 간단한 추가와 구독 새로 고침으로 복제 가능.

##### 큰, 추가 전용 테이블

- **추가 전용 테이블 복제**: `copy_data` 옵션을 `false`로 설정하여 미래 변경 사항만 복제 후, 백업에서 이전 데이터 백필.

##### 많은 업데이트가 있는 큰 테이블

- **업데이트가 많은 큰 테이블 복제**: 테이블 크기 축소, `VACUUM` 실행, 테이블 파티셔닝 고려.

### 테이블 복제 상태 확인

- **복제 상태 모니터링**: `pg_subscription_rel` 시스템 테이블을 통해 복제 상태 확인, 한 번에 하나의 테이블 복제 권장.

### 복제 중단

- **복제 중단 방법**: 필요 시 테이블 복제 중단 및 구독 새로 고침으로 롤백 가능.

### 복제 슬롯 이전에 대한 주의

- **복제 슬롯 이전 문제**: 복제 슬롯의 LSN은 기본 데이터베이스에 고유하므로 새 데이터베이스로 직접 복사 불가.

### 마이그레이션 마무리

- **테이블 일치성 검증**: 두 데이터베이스 간 테이블 행 수 일치 확인, 필요 시 무작위 샘플링으로 데이터 일치성 검증.

### 애플리케이션 수준 변경

- **데이터베이스 연결 변경**: 애플리케이션을 새 데이터베이스에 연결하도록 변경, 트래픽 전환 전략 수립.

### 시퀀스에 대한 추가 사항

- **시퀀스 동기화**: 복제 과정에서 시퀀스 값 동기화되지 않으므로, 수동으로 시퀀스 값을 설정.

### 최종 점검 체크리스트

- **최종 점검**: 테이블 일치성, 구독 상태, 스키마 일치, 데이터베이스 크기, 복제본 추가, 인덱스 재구성, 성능 테스트, 리스크 평가, 스테이징 환경에서의 연습.

### 최종 전환

- **최종 전환 실행**: 저녁 시간대에 테이블 복제, 스테이징 환경에서 여러 번 연습 후, 최종 점검 및 플래그 전환.

### GN⁺의 의견

- **중요성**: Knock은 제로 다운타임으로 Postgres 11.9에서 15.3으로 업그레이드하는 복잡한 과정을 성공적으로 수행함. 이는 데이터베이스 관리와 서비스 가용성에 중요한 이정표를 제시함.
- **흥미로움**: 복제 기반 업그레이드 접근법은 데이터베이스 관리자들에게 새로운 데이터베이스로의 부드러운 전환을 가능하게 하며, 이는 기술 커뮤니티에 큰 관심을 끌 수 있음.
- **재미**: Knock의 업그레이드 과정은 체계적인 리스크 관리와 문제 해결 과정을 통해 복잡한 기술적 도전을 극복하는 모범 사례를 보여줌.

## Comments



### Comment 21395

- Author: neo
- Created: 2023-12-14T10:03:34+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=38616181)   
- 대용량 테이블을 복사하는 것보다 더 나은 방법이 존재함.  
  - 복제 슬롯 생성, 스냅샷 취득, 새 인스턴스로 스냅샷 복원, LSN 진행, 복제 시작으로 논리적 복제본을 만들 수 있음.  
  - Instacart의 기사가 이 과정을 설명하고 있음.  
  - 기사에 작은 오류가 있을 수 있지만, TB 크기 인스턴스를 업그레이드하는 데 여러 번 성공적으로 사용함.  
  
- 여기서 제시된 접근법은 흥미롭고 잘 문서화되어 있지만, "현대 고객은 100% 가용성을 기대한다"는 문장에 동의하지 않음.  
  - 고객이나 공급자로서의 경험에 따르면, 가용성보다 일관성이 훨씬 중요함.  
  - 벤더가 다운타임을 공지할 때 데이터를 신중하게 다루고 있다는 신호로 받아들여 안도감을 느낌.  
  
- AWS가 이제 블루-그린 배포를 지원함.  
  
- 대부분의 문제를 자동화하는 도구를 작성함.  
  - 도구는 GitHub에서 공유되며, 피드백이나 아이디어를 통해 확장할 수 있음.  
  
- hava.io에서 AWS RDS PostgreSQL 11.13에서 15.5로 마이그레이션 중임.  
  - pglogical을 사용한 단방향 복제 방식을 선택함.  
  - 이 방식은 빠르지 않지만, 점진적으로 데이터베이스를 새 인스턴스로 복제하는 데 몇 일이 걸릴 수 있음.  
  - 스토리지 유형과 크기를 변경하는 더 많은 자유를 제공함.  
  
- 어떠한 다운타임도 Knock 서비스에는 받아들일 수 없다는 주장에 의문을 표함.  
  - 복잡한 시스템은 사고와 다운타임이 발생함.  
  - 사전에 공지된 15분 다운타임은 대부분의 SaaS 비즈니스에 문제가 되지 않음.  
  - 엔지니어링 시간을 제품 개발이나 개발 팀의 속도 향상에 투자하는 것이 사용자에게 더 만족을 줄 수 있음.  
  - 데이터베이스 마이그레이션에서 "적은 다운타임"과 "제로 다운타임" 마이그레이션을 만드는 데 드는 작업량 차이가 큼.  
  
- 백업에서 복제를 초기화할 수 없다는 것에 놀람.  
  - 기존 안정적인 DB 내용을 새 서버로 스트리밍하는 번거로움을 줄일 수 있었을 것임.  
  - "제로 다운타임"이라고 하지만, 실제로는 새 서버로 전환하는 몇 초간의 다운타임이 있음.  
  - 일관성 유지 방법에 대한 세부 사항이 누락됨.  
  - 롤백 옵션에 대한 언급이 없으며, 대규모 데이터에 대한 일회성 이전 작업을 수행할 때는 항상 이전 단계로 되돌릴 계획이 필요함.  
  
- 데이터베이스 자격증명만 입력하면 제로 다운타임으로 Postgres 업데이트를 수행하는 올인원 도구에 관심이 있는지 물음.  
  
- 시퀀스 사용에 대한 것이 흥미로움.  
  - 시퀀스 대신 주로 순차적 UUID나 HiLo 알고리즘을 사용함.  
  
- 분산 시스템에서 발생하는 문제는 적절한 sleep(1000)으로 해결할 수 있음을 농담으로 표현함.  
  - Postgres는 DBA에게 친숙하지 않은 시스템이지만, 예전보다는 나아짐.