|
Postgresql 14버 이 Primary Standby 로 두대 설치 되어있습니다.
대략적인 설정은 streaming replication 중이고 hot standby 로 사용중입니다.
max_standby_streaming_delay : 30s
hot_standby_feedback : false
로그를 보면 쿼리 시작 1초 미만의 시간내 아래 에러가 발생 했습니다.
ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
이 에러 로그가 왜 발생 하게 되었는지 알아보고 있지만 쉽지 않아 질문 드립니다.
1. 공식 문서(링크)에 max_standby_streaming_delay 설명을 보면 충돌시 Standby에 WAL 적용 전 까지 대기 시간 인것 처럼 쓰여있습니다.
그러면서도 두번째 문단에서는 취소 전 쿼리를 실행할 수 있는 길이는 아니다 라고 되어있습니다.
When hot standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in Section 26.4.2. max_standby_streaming_delay applies when WAL data is being received via streaming replication. If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in the postgresql.conf file or on the server command line.
Note that max_standby_streaming_delay is not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply WAL data once it has been received from the primary server. Thus, if one query has resulted in significant delay, subsequent conflicting queries will have much less grace time until the standby server has caught up again.
그렇다면 제가 받은 에러의 경우, WAL은 max_standby_streaming_delay시간만큼 거의 다 될때 까지 기다렸다가 다음 쿼리가 실행 될때 걸려들었다고 생각해도 되는것인가요? 맞다면 그 근거는 무엇일까요?
공식 문서상 문구가 애매해 이해가 잘 되지 않습니다.
2. 처음에 들었던 추측은 Vaccum에 의해 정리당한 경우 max_standby_streaming_delay만큼 기다려도 의미가 없어 즉시 취소 기능이 있는건 아닌지 의심했습니다. 혹시 이런 기능이 있을가요?
있다면 어디에서 이 내용을 찾아 볼 수 있을까요?
혹시 질문과 상황을 이해하는데 더 필요한 내용이 있다면 알려주시면 감사하겠습니다.
|
