[PostgreSQL] Replication Slot

과거에는 복제 슬롯(Replication Slot)이 없을 때, 스트리밍 복제에서 원본(Master)은 복제(Slave)의 상태를 알지 못하였고,

이에 따라 WAL 세그먼트를 관리하는 것은 어려운 일이었다.

 

 

그로 인하여 아래와 같은 문제점이 발생하게 되었다.

 

 

[예시]

 

마스터 서버에서 큰 트랜잭션이 일어나고 있고,

복제 서버가 정지 상태(시스템 패키지 업그레이드, 하드웨어 업그레이드 등의 이유) 일 때,

 

 

해당 복제 서버의 상태와 관계없이  마스터 서버에서는 트랜잭션을 마치고

체크포인트를 통과하면 트랜잭션 로그(WAL 세그먼트)를 제거를 하게 되는데,

 

정지된 복제 서버에서는, 복제본의 유지 관리가 중단되었기 때문에,

복제 지연이 크게 발생하여 재기동을 할 때, 아래 에러가 발생된다.

 

LOG:  started streaming WAL from primary at 0/73000000 on timeline 1

FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000000000000073 has already been removed

 

---

 

 

일반적으로  WAL 아카이브 스크립트를 postgresql.conf에 지정하여

WAL 파일을 하나 이상의 장기 아카이브 위치에 복사할 수 있고,

Stand-By 클라이언트나 다른 스트리밍 복제 클라이언트가 없는 경우 

아카이브 스크립트가 완료되면 서버는 WAL 파일을 삭제할 수 있다.

 

 

그러나 Crash 발생 시 복구 작업을 하기 위해서는 최신의 WAL 파일을 필요로 하고,

복제 지연이 크게 발생되어 있는 복제 서버에서 복제를 요청을 할 때 문제가 발생하게 된다.

 

 

이미 삭제가 되어 없는 WAL 파일을 마스터 서버로 요청하게 되는 것이다.

 

이러한 문제점을 Replication Slot을 통하여 해결하였다고 한다.

 

---

 

1. Replication Slot :

 

복제 슬롯은 마스터와의 연결이 끊어진 경우에도 복제본에 필요한 WAL 로그를 마스터 서버가 유지하도록 보장하는 PostgreSQL의 기능이다.

 

마스터 서버와 일부 Hot/Archive 서버가 있고, 이들 사이에서 스트리밍 복제를 실행하는 경우

복제본이 오프라인이거나 연결이 끊어진 경우에도 복제 슬롯을 사용하여 WAL 파일을 유지한다.

 

복제 서버가 오프라인이 되는 경우 메인 서버는 복제 서버가 얼마나 지연되는지 추적하고 복제 서버가 다시 연결될 때까지 파일이 필요한 WAL을 유지할 수 있다.

 

그 후 WAL 파일을 디코딩하여 복제본으로 재생한다.

 

• 마스터가 모든 복제본이 WAL 세그먼트를 수신할 수 있도록 충분한 WAL 세그먼트를 유지하는지 확인
• 마스터가 복제본에서 복구 충돌을 일으킬 수 있는 행을 제거하는 것을 방지
• 마스터는 모든 복제본에서 트랜잭션 로그를 사용한 후에만 트랜잭션 로그를 재활용이 가능

 

 

---

2. Replication Slot 유형 :

 

복제 슬롯에는 두 가지 유형이 있다.

 

 

1) 물리적 복제 슬롯(Physical replication slots) :

표준 스트리밍 복제에 사용된다.

 

 

 

2) 논리적 복제 슬롯(Logical replication slots) :

논리적 복제는 물리적 복제 슬롯과 동일한 작업을 수행하지만, 별도로 논리적 디코딩에도 사용된다는 차이가 있다.

 

논리적 디코딩은 사용자를 트랜잭션 로그에 연결하고 플러그인을 사용하여 디코딩할 수 있는 기회를 제공하는 것이다.

 

이를 통해, 데이터베이스에 대한 변경 사항을 추출할 수 있으므로 트랜잭션 로그에 대한 모든 형식과 목적의 변경 사항을 추출할 수 있게 되는 것이다.