max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
동시에 정의된 복제 슬롯의 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_slot_wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
복제 슬롯으로 예약할 수 있는 최대 WAL 크기를 설정합니다. 복제 슬롯은 실패로 표시되고, 디스크에서 WAL이 이 공간을 차지하는 경우 삭제 또는 재활용을 위해 세그먼트가 해제됩니다. |
| 데이터 형식 |
integer |
| 기본값 |
-1 |
| 허용되는 값 |
-1 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
max_slot_wal_keep_size |
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
400 |
| 허용되는 값 |
400 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
wal_keep_size |
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |
max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
동시에 정의된 복제 슬롯의 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_slot_wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
복제 슬롯으로 예약할 수 있는 최대 WAL 크기를 설정합니다. 복제 슬롯은 실패로 표시되고, 디스크에서 WAL이 이 공간을 차지하는 경우 삭제 또는 재활용을 위해 세그먼트가 해제됩니다. |
| 데이터 형식 |
integer |
| 기본값 |
-1 |
| 허용되는 값 |
-1 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
max_slot_wal_keep_size |
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
400 |
| 허용되는 값 |
400 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
wal_keep_size |
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |
max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
서버에서 지원할 수 있는 최대 복제 슬롯 수를 지정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_slot_wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
복제 슬롯으로 예약할 수 있는 최대 WAL 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
-1 |
| 허용되는 값 |
-1 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
max_slot_wal_keep_size |
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
400 |
| 허용되는 값 |
400 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
wal_keep_size |
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |
max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
서버에서 지원할 수 있는 최대 복제 슬롯 수를 지정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_slot_wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
복제 슬롯으로 예약할 수 있는 최대 WAL 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
-1 |
| 허용되는 값 |
-1 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
max_slot_wal_keep_size |
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
400 |
| 허용되는 값 |
400 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
wal_keep_size |
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |
max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
서버에서 지원할 수 있는 최대 복제 슬롯 수를 지정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_slot_wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
복제 슬롯으로 예약할 수 있는 최대 WAL 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
-1 |
| 허용되는 값 |
-1 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
max_slot_wal_keep_size |
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
400 |
| 허용되는 값 |
400 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
wal_keep_size |
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |
max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
서버에서 지원할 수 있는 최대 복제 슬롯 수를 지정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_slot_wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
복제 슬롯으로 예약할 수 있는 최대 WAL 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
-1 |
| 허용되는 값 |
-1 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
max_slot_wal_keep_size |
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_size
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 크기를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
400 |
| 허용되는 값 |
400 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
wal_keep_size |
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |
max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
서버에서 지원할 수 있는 최대 복제 슬롯 수를 지정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_segments
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 개수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
25 |
| 허용되는 값 |
25 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
|
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |
max_replication_slots
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
서버에서 지원할 수 있는 최대 복제 슬롯 수를 지정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
2-262143 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_replication_slots (최대 복제 슬롯) |
Azure 관련 메모
매개 변수의 max_replication_slots 기본값은 10입니다. 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4 max_replication_slots 가 필요합니다.
고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_replication_slots를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_replication_slot만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
max_wal_senders
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 발신자 프로세스를 동시에 실행하는 최대 수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
10 |
| 허용되는 값 |
5-100 |
| 매개 변수 형식 |
정적 |
| 문서 |
max_wal_senders |
Azure 관련 메모
Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 설정된 서버 매개 변수의 기본값 max_wal_senders 은 아래에서 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication줄여서는 안 됩니다.
상당한 수의 테이블의 논리적 복제에 대처하기 위해 훨씬 더 높은 값으로 늘려 max_wal_senders 야 할 필요성을 고려할 때 다음 중요한 사항을 염두에 두어야 합니다.
- 많은 수의 테이블을 논리적으로 복제하는 경우 반드시 많은 수의 WAL 보낸 사람이 필요하지는 않습니다.
- 테이블별 또는 테이블 그룹별로 별도의 WAL 발신자가 필요한 유일한 이유는 각 테이블 또는 그룹별로 별도의 구독이 필요한 경우입니다.
- 물리적 및 논리적 복제에 활용되는 WAL 보낸 사람의 수가 무엇이든, 백 엔드가 미리 쓰기 로그에 무언가를 쓸 때마다 모두 한 번에 활성화됩니다. 이런 일이 발생하면 논리적 복제를 수행하도록 할당된 WAL 보낸 사용자 모두가 다음을 수행하게 됩니다.
- WAL의 모든 새 레코드를 디코딩합니다.
- 관심 없는 로그 레코드를 필터링합니다.
- 각 데이터와 관련된 정보를 동일하게 복제하세요.
- WAL 보낸 사람은 연결과 비슷한데, 유휴 상태라면 보낸 사람의 수가 얼마인지는 중요하지 않습니다. 그러나 활성 상태인 경우 동일한 리소스를 놓고 경쟁하게 되며 성능이 크게 저하될 수 있습니다. 논리적 디코딩은 CPU 비용이 많이 들기 때문에 논리적 복제를 사용하는 보낸 사람에게는 특히 그렇습니다. 각 워커는 단일 테이블에만 영향을 미치는 작업의 복제에도 불구하고 전체 쓰기-앞서-로그(WAL)를 디코딩해야 하며, 이는 WAL의 모든 데이터 중 아주 작은 부분일 뿐입니다. 물리적 복제의 경우 WAL 보낸 사람이 CPU를 너무 많이 사용하지 않고 먼저 네트워크 대역폭에 의해 경계되는 경향이 있기 때문에 중요하지 않습니다.
- 따라서 일반적으로 vCore보다 더 많은 WAL 보낸 사람이 없는 것이 좋습니다.
- 향후 성장이나 복제 연결의 일시적인 급증을 고려하여, 몇 명의 추가 WAL 발송인에 대한 공간을 확보하는 것이 좋은 실천입니다. 다음 두 예제는 더 잘 설명하는 데 도움이 될 수 있습니다.
- vCore 8개, HA 사용 안 함, 읽기 복제본 2개 및 논리 복제 슬롯 3개인 서버의 경우 HA(0) + 읽기 복제본에 대한 실제 슬롯(2) + 논리 슬롯(3) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할
max_wal_senders 수 있습니다. 사용 가능한 vCore(1) = 6을 고려합니다.
- 16개의 vCore, HA 사용, 4개의 읽기 복제본 및 5개의 논리적 복제 슬롯이 있는 서버의 경우 사용 가능한 vCore(2) =
max_wal_senders을 고려하여 HA(2) + 읽기 복제본에 대한 실제 슬롯(4) + 논리 슬롯(5) + 향후 성장을 위한 몇 가지 추가 슬롯의 합계로 구성할 수 있습니다.
- 고가용성을 사용하도록 설정하는 경우 고가용성이 제대로 작동하려면 최소 4
max_wal_senders 가 필요합니다. 고가용성이 활성화된 서버, 읽기 복제본 5개 및 논리적 복제 슬롯 12개가 있는 경우, max_wal_senders를 21로 설정할 수 있습니다. 이는 각 읽기 복제본과 각 논리 복제 슬롯에 하나 max_wal_senders만 필요하기 때문입니다. 따라서 총 1개(슬롯) * 5개(읽기 복제본) + 12개(논리 복제 슬롯) + 4개(고가용성 기능용) = 21개가 필요합니다.
- 이 매개 변수에 허용되는 최대값이 요구 사항에 비해 너무 낮다는 점을 고려한다면 , Microsoft에 문의하고, 시나리오를 자세히 설명하고, 시나리오가 제대로 수행하는 데 필요한 최소 허용 값이라고 생각하는 사항을 설명해 주세요.
커밋 타임스탬프 추적
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
트랜잭션 커밋 시간을 수집합니다. |
| 데이터 형식 |
boolean |
| 기본값 |
off |
| 허용되는 값 |
on,off |
| 매개 변수 형식 |
정적 |
| 문서 |
track_commit_timestamp |
wal_keep_segments
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
대기 서버에 대해 보유되는 WAL 파일의 개수를 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
25 |
| 허용되는 값 |
25 |
| 매개 변수 형식 |
읽기 전용 |
| 문서 |
|
wal_sender_timeout
| 특성 |
가치 |
| 카테고리 |
복제/송신 서버 |
| Description |
WAL 복제를 기다리는 최대 시간을 설정합니다. |
| 데이터 형식 |
integer |
| 기본값 |
60000 |
| 허용되는 값 |
0-2147483647 |
| 매개 변수 형식 |
dynamic |
| 문서 |
wal_sender_timeout |