PostgreSQL14 Replication 관련 파라미터

Replication을 사용할 때, 확인 해보면 좋은 파라미터들 입니다!

wal_keep_size (13버전부터 이름이 변경됐음)

standby 서버에 대해 보관된 WAL 파일의 크기를 설정합니다

default	0(disable)
단위	MB
재시작 여부	X

• standby 서버가 스트리밍 복제를 위해 과거 로그 파일 세그먼트를 가져와야 하는 경우 pg_wal 디렉토리에 보관되는 최소 로그 파일 세그먼트 크기를 지정합니다. sending 서버에 연결된 standby 서버가 wal_keep_size 이상 뒤처지는 경우, sending 서버는 대기에 필요한 WAL 세그먼트를 제거할 수 있으며, 이 경우 replication 연결이 종료됩니다. (그러나 WAL 아카이빙이 사용 중인 경우에는 아카이브에서 세그먼트를 가져와 standby 서버를 복구할 수 있습니다)
• PostgreSQL Replication에서 primary 서버는 데이터베이스의 모든 변경 사항에 대한 내용을 WAL에 기록합니다. standby 서버는 이 WAL을 사용하여 변경 사항을 적용합니다. 사용자가 primary를 standby에 백업한 후 바로 연결하지 않거나, primary 서버와 standby 서버간의 네트워크 연결이 느린 경우에 다음과 같은 문제가 생길 수 있습니다.
• standby 서버가 primary 서버의 WAL파일을 읽어 변경 사항을 적용해야하는데 적용하기 전에 primary 서버가 WAL 파일을 재활용 하게되어 standby 서버가 primary 서버의 변경 사항을 적용할 수 없게됩니다. 이 문제를 방지하기위해 PostgreSQL은 wal_keep_size 라는 파라미터를 제공합니다.
• wal_keep_size는 replication에 더이상 필요하지 않은 경우에도 primary 서버에 유지되어야하는 WAL의 최소 size, 즉 개수를 지정합니다. 이 size를 유지함으로써 primary 서버의 WAL이 재활용 되기 전에 standby 서버가 연결하고 WAL파일을 적용할 만한 충분한 시간을 갖게 해줍니다.
• 기본값인 0으로 설정하게 되면 primary 서버에 남는 WAL파일의 개수는 체크포인트 위치와 WAL 아카이빙 상태에 따라 달라집니다. 그렇기 때문에 이 파라미터를 0으로 사용하는 경우는 주의하여 사용해야합니다. 네트워크 문제가 전혀 없거나, 디스크 공간 확보가 중요하며 WAL 보존이 그렇게 우선 순위가 아닌 경우에 적합할 수 있습니다.

max_standby_streaming_delay

hot standby 모드일 때, standby 서버가 적용한 WAL 파일과 충돌하는 stnadby 쿼리를 취소하기 전에 대기해야 하는 시간을 지정합니다.

default	30000 (30s)
단위	milliseconds (ms)
재시작 여부	X

primary 와 standby 서버 사이에 다음과 같은 여러 충돌이 발생할 수 있습니다.

• primary 서버에서 수행된 exclusive lock이 standby 쿼리의 테이블 access와 충돌합니다.
• primary 에서 데이터베이스를 삭제하면 대기중인 해당 데이터베이스에 연결된 세션과 충돌합니다.
• WAL 세그먼트를 정리하는 VACUUM은 대상 페이지에 액세스 하는 standby 쿼리와 충돌합니다.

primary 서버에서 이런 경우엔 단순히 대기하고, 사용자는 충돌이 발생한 작업을 취소할 수 있습니다. 그러나 standby 서버에서는 선택의 여지가 없고 이미 primary 의 WAL에 기록이 됐기 때문에 standby에서도 적용을 해야합니다. 그리고 무기한 대기하도록 하는 것은 standby가 primary서버의 상태보다 점점 뒤처지기 때문에 바람직 하지 않습니다. 따라서 PostgreSQL은 적용할 WAL 레코드와 충돌하는 standby 쿼리를 강제로 취소하는 매커니즘을 제공합니다.

예를 들어, standby 서버에서 현재 쿼리에서 액세스하고 있는 테이블을 primary 에서 DROP 하려고 할때, 이 쿼리가 실행 중인 동안 WAL 변경 레코드가 standby로 전달되어 충돌이 발생합니다. standby 서버는 WAL 레코드 적용을 지연시키거나 충돌하는 쿼리를 취소하여 DROP TABLE을 적용해야 합니다. 충돌하는 쿼리는 새로 수신된 WAL 데이터를 적용하는 데 max_standby_streaming_delay 설정보다 오래 걸리면 취소됩니다.

주로 고가용성을 위해 존재하는 standby 서버에서는 대기 쿼리로 인한 지연으로 인해 서버가 primary 서버보다 크게 뒤처지지 않도록 max_standby_streaming_delay를 비교적 짧게 설정하는 것이 가장 좋습니다. 그러나 standby 서버가 장기간 실행되는 쿼리를 실행하기 위한 것인 경우에는 max_standby_streaming_delay 값이 높거나 무한한 것이 좋습니다. 그러나 WAL 레코드 적용 지연 시간이 길어지기 때문에 standby 서버의 다른 세션에서 최근 변경사항이 나타나지 않을 수 있습니다.

hot_standby_feedback

hot standby 에서 primary로 피드백을 보내서 쿼리 충돌을 방지합니다.

default	off
재시작 여부	X

핫 스탠바이가 현재 스탠바이에서 실행 중인 쿼리에 대한 피드백을 기본 스탠바이 또는 업스트림 스탠바이로 보낼지 여부를 지정합니다.

standby 서버가 실행 중인 가장 오래된 트랜잭션 ID(xmin)를 primary로 보냅니다. 그러면 primary 가 standby에서 실행 중인 쿼리가 특정 데이터를 관찰하고 있음을 알 수 있습니다. 따라서 VACUM은 더 이상 충돌이 발생할 수 없을 때까지 지연될 것입니다

이 매개 변수를 사용하여 충돌에 의한 쿼리 취소를 없앨 수 있지만 VACUUM이 미뤄지기 때문에, 데이터베이스가 부풀려질 수 있습니다.