위의 @ max-malysh의 훌륭한 답변에 대한 업데이트 된 정보와 참조를 추가 할 것입니다.
즉, 마스터에서 무언가를 수행하면 슬레이브에서 복제해야합니다. Postgres는이를 위해 WAL 레코드를 사용합니다.이 레코드는 마스터에서 기록 된 모든 작업 후에 슬레이브로 전송됩니다. 그런 다음 슬레이브는 작업을 실행하고 두 개는 다시 동기화됩니다. 여러 시나리오 중 하나에서 WAL 작업의 마스터에서 들어오는 내용과 슬레이브가 충돌 할 수 있습니다. 대부분의 경우 슬레이브에서 트랜잭션이 발생하여 WAL 작업이 변경하려는 항목과 충돌합니다. 이 경우 두 가지 옵션이 있습니다.
- WAL 조치 적용을 약간 지연시켜 슬레이브가 충돌하는 트랜잭션을 완료 한 후 조치를 적용하십시오.
- 슬레이브에서 충돌하는 쿼리를 취소하십시오.
우리는 # 1과 두 가지 값에 관심이 있습니다.
max_standby_archive_delay
-이것은 현재 데이터가 아닌 WAL 아카이브에서 데이터를 읽을 때 마스터와 슬레이브 간의 긴 연결 해제 후 사용 된 지연입니다.
max_standby_streaming_delay
-스트리밍 복제를 통해 WAL 항목이 수신 될 때 쿼리 취소에 사용되는 지연.
일반적으로 서버가 고 가용성 복제 용인 경우이 숫자를 짧게 유지하려고합니다. 기본 설정 30000
(단위가 없으면 밀리 초)으로 충분합니다. 그러나 매우 오래 실행되는 쿼리가있을 수있는 아카이브,보고 또는 읽기-복제본과 같은 것을 설정하려면 취소 된 쿼리를 피하기 위해이 값을 더 높게 설정해야합니다. 900s
위 의 권장 설정은 좋은 시작점처럼 보입니다. 무한한 값 -1
을 좋은 아이디어로 설정하는 것에 관한 공식 문서에 동의하지 않습니다. 버그가있는 코드를 숨기고 많은 문제를 일으킬 수 있습니다.
장기 실행 쿼리 및 이러한 값을 더 높게 설정하는 한 가지 경고는 장기 실행 쿼리와 병렬로 슬레이브에서 실행중인 다른 쿼리가 장기 쿼리가 완료 될 때까지 이전 데이터를 볼 수 있다는 것입니다. 개발자는이를 이해하고 동시에 실행해서는 안되는 쿼리를 직렬화해야합니다.
방법 max_standby_archive_delay
과 max_standby_streaming_delay
작업 및 이유에 대한 전체 설명을 보려면 여기로 이동하십시오 .