PostgreSQL / PPAS Streaming Replication 사용 시, DDL 로 발생하는 lock 에 대한 주의사항

이 페이지에서는 PostgreSQL / PPAS Streaming Replication 사용 시, DDL 로 발생하는 lock 에 대한 주의사항을 다룬다.

 

이 페이지는 아래의 공식 문서, 이전 게시글, 기타 외부 링크와 연관되어 있다.

 

[1] https://www.postgresql.org/docs/13/warm-standby.html#STREAMING-REPLICATION

 

[2] 2021.03.08 - [PostgreSQL/Replication] - Streaming Replication

 

[3] 2023.07.08 - [PostgreSQL/기타 지식] - PostgreSQL / PPAS DDL 수행 시 발생하는 lock 의 유의성

 

[4] https://serverfault.com/questions/1083651/should-replica-db-be-in-recovery-postgresql

 

 

Streaming Replication 의 과정 

 

[2] 의 내용과 같이 Streaming Replication 에서는 master 에서 walsender 가 reader (또는 replica) 로 WAL 파일을 보내고 이를 reader 의 walreiceiver 가 WAL 파일을 읽어 들이면서 역으로 WAL 파일 내 트랜잭션을 구현하는 과정을 거친다.

 

일반적으로 replication 은 단방향 동기화이기에 master 에서 어떠한 쿼리를 전송해도 문제가 될 것 같지 않아 보이나

 

PostgreSQL / PPAS 는 [3] 의 내용과 같이 DDL 을 수행 시 발생되는 lock 의 범위 및 영향이 큰데 이 사항 과 동기화 과정이 맞물려서 문제가 발생한다.

 

 

DDL 을 수행 시, reader 에서도 lock 이 발생하는 위험성

 

Reader 에서도 master 가 수행했던 트랜잭션을 동일하게 구현하면 master 와 같이 lock 이 발생한다. 그러면 DDL 등의 변경 작업을 수행 할 수 없는 reader 에서도 이로 인해 쿼리들에 부하가 걸려서 CPU 사용량 등이 급증 할 수 있다. 그 뿐만 아니라 reader 에서는 [4] 와 같이 수행되는 트랜잭션들에 대해서 WAL file 을 master 와 같이 구현하는데 이를 recovery 형식으로 구현하는 과정에서 위의 동기화 작업이 대기상태로 빠지면 이 recovery 작업도 대기상태에 빠지기 때문에 이로 인해 이후에 이 상태에서 갑작스러운 crash 가 발생하면 WAL file 이 제대로 동기화 되어 있지 않으니 이에 대한 복구 작업에 문제가 생길 수 있다.

 

그렇기에 streaming replication 을 사용하는 환경에서는 DDL 을 매우 신중하게 사용하는 것이 좋다.