논리 복제 및 디코딩 설정

MySQL | PostgreSQL | SQL Server

PostgreSQL용 Cloud SQL에서 논리적 복제 및 디코딩 기능을 사용할 수 있습니다. 이러한 기능은 논리적 복제 워크플로 및 변경 데이터 캡처(CDC) 워크플로를 가능하게 해줍니다.

복제에 대한 일반적인 내용은 Cloud SQL의 복제 정보를 참조하세요.

소개

PostgreSQL이 논리적 복제를 수행할 때 복제본에 스트리밍되는 변경사항은 논리적 디코딩을 사용하여 WAL 로그에서 추출됩니다. 디코딩된 변경사항은 기본 물리적 스토리지 형식과 별개입니다. 이러한 변경사항은 SQL 수준에서 INSERT, UPDATE, DELETE 측면의 데이터 변경사항만 반영합니다. 이렇게 스토리지 레이어를 구분하여 큰 유연성을 얻고, 변경 스트림 소비자별로 다양한 기능을 지원할 수 있습니다.

논리 복제는 논리적 디코딩을 기반으로 하는 플래그십 기능입니다.

소스 데이터베이스와 대상 데이터베이스의 버전이 동일해야 하는 PostgreSQL의 물리적 복제 기능과 달리 논리 복제에서는 PostgreSQL 주요 버전 간의 복제가 가능합니다. Cloud SQL의 논리 복제는 모든 PostgreSQL 버전에서 사용할 수 있는 pglogical 확장 프로그램과 PostgreSQL 10에 추가된 PostgreSQL의 기본 논리 복제에서 지원됩니다.

다양한 플러그인을 사용해 변경사항이 스트리밍되는 형식을 구성할 수 있습니다. 덕분에 유연한 변경 데이터 캡처(CDC) 아키텍처를 사용할 수 있습니다. 예를 들어 wal2json 확장 프로그램을 사용하면 데이터베이스의 모든 변경사항을 JSON 형식으로 소비자에게 스트리밍할 수 있습니다. Cloud SQL은 기본 제공되는 pgoutput 디코더, test_decoding contrib 모듈, wal2json을 지원합니다. Cloud SQL은 현재까지JSON 출력의 wal2json 변형을 모두 지원합니다. format-version 1은 전체 트랜잭션을 단일 JSON 객체로 인코딩하고 format-version 2는 명령어별로 1개의 JSON 객체를 출력합니다. 이러한 플러그인은 PostgreSQL 이외의 데이터베이스에 대한 복제를 사용 설정합니다.

PostgreSQL 인스턴스 구성

PostgreSQL에서는 추가 정보를 미리 쓰기 로그(WAL)에 기록하여 논리 디코딩을 지원합니다.

Cloud SQL에서 cloudsql.logical_decoding 플래그를 on으로 설정하여 이 기능을 사용 설정합니다. 이 설정은 표준 PostgreSQL에 사용되는 설정과 다릅니다. 외부 PostgreSQL 인스턴스를 변경할 경우 wal_level 구성 매개변수를 logical로 설정하여 이 기능을 사용 설정합니다.

pglogical 확장을 사용하려면 pglogical을 shared_preload_libraries에 추가해야 합니다. Cloud SQL에서는 이 플래그를 직접 수정할 수 없으므로 cloudsql.enable_pglogical을 on으로 설정하여 pglogical을 사용 설정합니다. (VM에서 sudo apt-get으로 postgresql-13-pglogical을 설치하고) 데이터베이스를 다시 시작합니다.

pglogical을 사용하여 두 PostgreSQL 인스턴스 간에 복제를 수행하는 경우 복제본 인스턴스가 아닌 기본 인스턴스에서만 논리적 디코딩을 사용 설정하면 됩니다(인스턴스 자체가 다른 복제본의 기본 인스턴스가 아닌 경우) 하지만 pglogical 확장은 두 인스턴스 모두에서 사용 설정되어야 합니다. '기본' 및 '복제본' 용어의 사용 예시와 의미를 보려면 Cloud SQL의 복제 정보를 참조하세요.

네트워크 연결 사용 설정

기본 인스턴스가 복제본 인스턴스의 연결을 수락하는지 확인합니다.

기본	복제본	구성
Cloud SQL(공개 IP)	Cloud SQL(공개 IP)	복제본의 발신 IP 주소를 기본 인스턴스의 승인된 네트워크에 추가합니다.
Cloud SQL(비공개 IP)	Cloud SQL(비공개 IP)	두 인스턴스 모두 같은 Google Cloud 프로젝트에 있는 경우 인스턴스를 호스팅하는 승인된 네트워크에 복제본 VPC 네트워크의 할당된 IP 범위를 추가합니다. Google Cloud Console에서 할당된 IP 범위를 찾으려면 다음 안내를 따르세요. VPC 네트워크 페이지로 이동합니다. 사용 중인 VPC 네트워크를 선택합니다. 비공개 서비스 연결 탭을 선택합니다. 할당된 IP 범위 탭을 선택합니다. 참고: VPC 네트워크의 서브넷이 10.0.0.0/8, 172.16.0.0/12 또는 192.168.0.0/16 범위에 포함된 경우 이러한 서브넷 블록이 기본적으로 각 인스턴스에서 ACL로 설정되기 때문에 어느 한 인스턴스의 승인된 네트워크에 아무 것도 추가할 필요가 없습니다.
외부	Cloud SQL	Database Migration Service를 사용할 수 있습니다.
Cloud SQL	외부	자세한 내용은 외부 복제본 구성을 참조하세요.

복제본 인스턴스의 발신 IP 주소 가져오기

복제본 인스턴스가 Cloud SQL 인스턴스이고 공개 IP 주소가 있으면 다음 단계를 수행하여 발신 IP 주소를 가져오세요.

콘솔

Cloud SQL 인스턴스 페이지를 엽니다.
Cloud SQL 복제본의 공개 IP 주소 옆에 있는 추가 정보 도구 도움말 위로 마우스를 가져가 발신 IP 주소를 검색합니다. 발신 IP 주소는 Cloud 콘솔에서 복제본의 주요 목록에 표시되는 IP 주소가 아닙니다.

복제본 인스턴스가 Cloud SQL 인스턴스가 아니면 관련 문서를 참조하세요.

인스턴스의 공개 IP 주소를 가져오는 방법에 대한 자세한 내용은 Cloud SQL 복제본의 발신 IP 주소 확인을 참조하세요.

gcloud

다음 gcloud 명령어를 사용하면 됩니다.

gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"

연결 허용

기본 인스턴스가 Cloud SQL 인스턴스인 경우 승인된 네트워크로 추가하여 복제본의 발신 IP 주소에서의 액세스를 허용할 수 있습니다.

PostgreSQL 9.6 및 이전 버전의 복제 연결 사용 설정

기본 인스턴스가 Cloud SQL에서 실행되지 않고 PostgreSQL 9.6 이전 버전을 실행하는 경우 인스턴스의 pg_hba.conf 파일이 복제 연결을 허용하도록 설정되어 있는지 확인해야 합니다. 초기 테스트에서만 all all을 사용하여 파일에 다음 줄을 추가합니다. 보안을 강화하려면 다음 예시와 같이 사용자와 IP 주소를 필요한 만큼으로 제한합니다.

host replication all all md5

자세한 내용은 pg_hba.conf 파일을 참조하세요.

복제 사용자 만들기

논리 디코딩 기능을 사용하려면 REPLICATION 속성으로 PostgreSQL 사용자를 만듭니다.

예시

CREATE USER replication_user WITH REPLICATION
IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secret';

또는 기존 사용자에 이 속성을 설정할 수 있습니다.

ALTER USER existing_user WITH REPLICATION;

PostgreSQL 리소스

논리 디코딩이 사용되는 경우 기본 PostgreSQL 인스턴스에서 백그라운드 프로세스가 선택된 디코딩 플러그인을 사용하여 WAL 변경사항을 논리적 변경사항으로 변환하고 이를 소비자(또는 비PostgreSQL 인스턴스일 수도 있음)로 릴레이합니다. 이 백그라운드 프로세스를 WAL 발신자라고 부릅니다. PostgreSQL 인스턴스에서 활성 상태일 수 있는 동시 WAL 발신자 수는 max_wal_senders 플래그로 제한됩니다. 이 플래그는 기본값이 10이고 Cloud SQL 인스턴스의 메모리에 따라 선형적으로 해당 한도가 증가하며, 1GB 메모리당 8개의 WAL 발신자가 허용됩니다.

모든 소비자에 전송되기 전 WAL 세그먼트가 삭제되지 않도록 PostgreSQL는 논리 복제 슬롯을 사용하여 소비자에 전송되는 데이터를 추적합니다(읽기 복제본에는 물리 복제 슬롯 사용). PostgreSQL 인스턴스에 대해 만들 수 있는 복제 슬롯 수는 max_replication_slots 플래그로 제한됩니다. 이 플래그는 기본값이 10이고 Cloud SQL 인스턴스의 메모리에 따라 해당 한도가 증가하며, 1GB 메모리당 2~8개의 복제 슬롯이 허용됩니다.

다음 표에서는 Cloud SQL 인스턴스의 최대 메모리와 인스턴스의 최대 복제 슬롯 사이의 관계를 보여줍니다.

최대 메모리(GB)	최대 복제 슬롯
4	10
16	32
32	128
64	256
128	512
256	1024
512	2048
512+	4096

일반적으로 복제 슬롯과 WAL 발신자는 소비자마다 하나씩 있으므로 이러한 플래그는 거의 동일한 값으로 설정해야 합니다. 하지만 PostgreSQL에서는 연결이 예기치 않게 중단되고 새 연결이 이루어진 경우를 처리하기 위해 max_wal_senders에 대한 작은 버퍼를 제공하는 것이 좋습니다. Cloud SQL 읽기 복제본에서 사용되는 물리적 복제도 복제 슬롯과 WAL 발신자를 사용하므로 필요한 각 리소스 수를 계산할 때 이를 반영해야 합니다.

PostgreSQL 기본 논리적 복제 및 pglogical은 기본 및 복제본 인스턴스 모두에서 추가적인 백그라운드 프로세스를 실행해야 합니다. 실행할 수 있는 백그라운드 프로세스 수는 max_worker_processes 플래그로 제한됩니다. 기본값은 8이고 Cloud SQL 인스턴스의 메모리에 따라 선형적으로 해당 한도가 증가하며, 1GB 메모리당 2개의 추가 프로세스가 허용됩니다. 이러한 접근 방법에 사용되는 작업자 프로세스의 정확한 개수는 해당 섹션에서 설명합니다.

이 플래그의 값이 너무 낮게 설정된 경우 로그의 worker registration failed 오류 메시지와 함께 복제가 실패하면 max_worker_processes 설정을 늘려야 할 수 있습니다.

참고로 WAL 발신자는 작업자 프로세스로 집계되지 않습니다. 병렬 쿼리 실행을 위해 생성되는 작업자 수는 계산됩니다. 따라서 max_worker_processes 값을 너무 낮게 설정하면 PostgreSQL에서 병렬 쿼리 실행을 활용할 수 없으므로 성능이 저하될 수 있습니다.

pg_ls_waldir () 함수를 사용하여 WAL 디스크 사용량을 결정할 수 있습니다. 이 함수는 기본 관리자 사용자 postgres와 같은 cloudsqlsuperuser 사용자로 제한됩니다. 이 함수는 PostgreSQL 버전 10 이상에서만 사용할 수 있습니다.

총 WAL 디스크 사용량을 계산하려면 다음 안내를 따르세요.

postgres=> select * from pg_ls_waldir();

이름	크기	수정
00000001000000000000000A	16777216	2021-08-11 15:16:49+00
000000010000000000000009	16777216	2021-08-12 06:23:24+00

(2개 행)

postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();

총 WAL 디스크 사용량
32MB

(1개 행)

외부 복제본으로 논리적 복제 설정

pglogical 및 logical 디코딩을 사용하는 전체 예시는 외부 복제본 구성을 참조하세요.

pglogical로 논리 복제 설정

pglogical으로 논리 복제를 설정하려면 기본 인스턴스에 논리 디코딩이 사용 설정되어야 합니다. Cloud SQL 인스턴스에 cloudsql.logical_decoding=on을 설정하거나 외부 인스턴스에 wal_level=logical을 설정합니다. 또한 기본 인스턴스와 복제본 인스턴스 모두에 pglogical을 사용 설정해야 합니다. Cloud SQL 인스턴스에 cloudsql.enable_pglogical=on을 설정하거나 외부 인스턴스의 shared_preload_libraries에 pglogical을 추가합니다. 이 플래그를 변경하려면 기본 인스턴스와 복제본 인스턴스를 모두 다시 시작해야 합니다.

이 단계에서 문제가 발생하면 pglogical 문제 해결을 참조하세요.

복제 권한이 있는 사용자 만들기

pglogical을 사용할 때 기본 인스턴스와 복제본 인스턴스 모두에 대한 cloudsqlsuperuser 역할과 복제 권한이 있는 사용자가 필요합니다. 이러한 사용자가 아래에 설명된 명령어를 실행해야 합니다.

pglogical 확장 설치

기본 인스턴스와 복제본 인스턴스 모두에 pglogical 확장 프로그램을 설치해야 합니다. 기본 인스턴스에서는 복제 사용자(데이터베이스에 연결하는 사용자)가 이를 설치해야 합니다.

CREATE EXTENSION pglogical;

각 인스턴스에서 pglogical 노드 만들기

pglogical 노드는 물리적 PostgreSQL 인스턴스를 나타내며 해당 인스턴스에 대해 연결 세부정보를 저장합니다. 기본 및 복제본 인스턴스 모두 노드로 등록되어야 합니다.

source-instance$ SELECT pglogical.create_node(
    node_name := 'primary',
    dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

dest-instance$ SELECT pglogical.create_node(
    node_name := 'replica',
    dsn := 'host=<replica-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

복제할 데이터로 테이블 만들기

pglogical 확장은 테이블 일부만 대상에 복제하도록 허용합니다. 예를 들어 기본 인스턴스에 더미 테이블을 만들고 테스트할 일부 데이터로 채워보겠습니다.

CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');

복제본 인스턴스에도 테이블을 만들어야 합니다.

복제 세트에 테이블 추가

다른 데이터 세트를 서로 다른 대상에 복제하도록 지원하기 위해 pglogical에는 복제 세트라는 개념이 포함되어 있습니다. 기본 복제 세트에 테스트 테이블을 추가할 수 있습니다.

SELECT pglogical.replication_set_add_table('default', 'replica_test', true);

pglogical 구독 만들기

기본 인스턴스에 연결 세부정보를 제공하여 대상 인스턴스에 pglogical 구독을 만듭니다.

SELECT pglogical.create_subscription(
    subscription_name := 'test_sub',
    provider_dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
);

SELECT * FROM pglogical.show_subscription_status('test_sub');

상태가 '복제 중'으로 표시되면 설정이 성공한 것입니다. replica_test 테이블을 쿼리하여 데이터가 복제되었는지 확인합니다. 기본 인스턴스에서 레코드를 삽입 및 수정하고 복제본 인스턴스에 표시되는지 확인합니다.

기본 인스턴스에서 pg_replication_slots 테이블을 쿼리하여 구독에서 만든 복제 슬롯을 확인합니다.

삭제

테스트가 성공한 후 pglogical.drop_subscription('test_sub')을 사용하여 복제본에서 구독을 삭제합니다. 복제 슬롯도 기본 인스턴스에서 삭제되었는지 확인합니다. 그렇지 않으면 WAL 세그먼트가 복제본 인스턴스에서 계속 누적됩니다.

복제 세트, 부분 데이터 복제, DDL 복제, 기타 고급 구성 및 제한사항에 대한 상세 설명은 pglogical 문서를 참조하세요.

리소스 사용량

pglogical 확장 프로그램은 max_worker_processes 한도에 집계되는 여러 백그라운드 프로세스를 실행합니다.

안정적인 상태에서 사용 설정된 경우 '감독자' 프로세스를 하나 실행하고 확장 프로그램을 설치한 PostgreSQL 데이터베이스마다 하나의 '관리자' 프로세스(D 등)를 실행하며 복제본 인스턴스의 pglogical 구독마다 하나의 '적용' 프로세스(S 등)를 실행합니다. 그러나 확장 프로그램에서 초기 동기화를 수행할 때 추가 작업자 프로세스를 생성할 수 있으며 실제로 인스턴스의 모든 데이터베이스에 대한 '관리자' 프로세스를 생성하지만 데이터베이스에 확장 프로그램이 설치되어 있지 않으면 즉시 종료됩니다.

따라서 안정적인 상태에서 필요한 것보다 조금 더 많은 수의 작업자 프로세스를 할당하세요. 작업자 프로세스는 PostgreSQL에서 병렬 쿼리 처리 등의 다른 용도로 사용됩니다. max_worker_processes 값이 너무 낮게 설정되면 복제가 자동으로 실패하거나 PostgreSQL에서 병렬 쿼리 처리를 수행하지 못할 수 있습니다.

요약하자면 다음 설정을 사용하는 것이 좋습니다.

max_worker_processes
  >= 1 + D + 8 (on the source instance)
  >= 1 + D + S + 8 (on the destination instance)
max_wal_senders >= S + 2 (on the source instance)
max_replication_slots >= S (on the source instance)

pglogical 문제 해결

pglogical 확장을 만들 수 없음

pglogical 확장 프로그램을 설치하려고 할 때 오류가 표시될 수 있습니다.

ERROR:  pglogical is not in shared_preload_libraries

Cloud SQL 인스턴스에 pglogical을 설치하는 경우 cloudsql.enable_pglogical=on을 설정했는지 확인합니다. 외부 인스턴스를 사용하는 경우에는 shared_preload_libraries 플래그에 직접 추가합니다(예: shared_preload_libraries=pg_stat_statements,pglogical). 수정사항을 적용하려면 기본 인스턴스를 다시 시작해야 합니다.

pglogical 구독을 만들 수 없음

구독을 만들 때 pglogical에서 먼저 연결 세부정보를 사용하여 인스턴스에 연결할 수 있는지 확인합니다. 먼저 일반 연결을 만들려고 시도하는데 실패하면 ERROR: could not connect to the postgresql server 오류가 발생합니다.

이 오류가 발생하면 기본 인스턴스가 복제본 인스턴스에서의 연결을 허용하도록 구성되었는지 확인하고 제공한 연결 세부정보가 올바른지 확인합니다. PostgreSQL이 연결을 설정할 수 없는 이유에 대한 세부정보가 제공됩니다.

일반적인 연결을 만든 후 pglogical은 특수한 복제 연결을 만들려고 시도합니다. PostgreSQL 9.6 이하에서는 이 유형의 연결이 다른 인증 구성을 가질 수 있습니다. ERROR: could not connect to the postgresql server in replication mode 오류가 표시되면 소스 인스턴스에서 pg_hba.conf 파일을 업데이트해야 합니다.

Cloud SQL에서 사용하는 pg_hba.conf 파일에 이미 필요한 변경사항이 포함되어 있습니다. 이 오류는 Cloud SQL에서 관리하지 않는 외부 인스턴스에 연결할 때만 발생합니다.

또는 소스 인스턴스에서 충분한 수의 WAL 발신자를 허용하지 않아도 복제 모드 연결이 실패할 수 있습니다. FATAL: number of requested standby connections exceeds max_wal_senders가 표시되면 기본 인스턴스에서 max_wal_senders를 늘리세요.

pglogical 구독이 정지됨

pglogical 구독 복제가 실패할 수 있습니다. 이 문제를 해결하려면 먼저 백그라운드 프로세스가 복제본 인스턴스에서 실행되는지 확인합니다. pg_stat_activity를 쿼리하여 pglogical apply 프로세스가 실행 중인지 확인합니다. 그렇지 않으면 대상 노드에서 로그를 확인합니다. worker registration failed, 메시지가 표시되면 max_worker_processes 설정을 늘릴 수 있습니다.

그런 다음 기본 인스턴스에 복제 슬롯이 생성되었는지 확인하세요. 복제본 인스턴스에서는 pglogical.subscription의 행에 구독이 만들려고 하는 슬롯의 이름이 포함되며, 기본 인스턴스에서는 pg_replication_slots을 쿼리하여 슬롯이 성공적으로 생성되었는지 확인할 수 있습니다.

복제 슬롯이 생성되지 않았다면 기본 인스턴스의 로그를 확인합니다.

ERROR: logical decoding requires wal_level >= logical의 오류는 wal_level 플래그가 logical로 설정되지 않았다는 의미입니다. 이 문제를 해결하려면 Cloud SQL 인스턴스인 경우 기본 인스턴스에서 cloudsql.logical_decoding=on을 설정합니다.

외부 인스턴스인 경우에는 wal_level=logical을 설정합니다.

그러지 않으면 유용한 HINT: Free one or increase max_replication_slots와 함께 ERROR: all replication slots are in use가 표시될 수 있습니다.

기본 PostgreSQL 논리 복제 설정

PostgreSQL에서는 PostgreSQL 10부터 기본 논리 복제를 기본적으로 제공합니다. 기본 논리 복제를 설정하려면 Cloud SQL 인스턴스에서 cloudsql.logical_decoding=on을 설정하거나 외부 인스턴스에서 wal_level=logical을 설정하여 기본 인스턴스에 논리 디코딩을 사용 설정해야 합니다. 이 플래그를 수정하려면 기본 인스턴스를 다시 시작해야 합니다.

PostgreSQL 인스턴스 구성의 섹션을 검토하여 네트워크 연결 등을 위해 인스턴스가 올바르게 구성되었는지 확인합니다. 이 페이지에서는 개념 증명 단계를 설명합니다. 해당 섹션의 단계를 수행하는 동안 문제가 발생하면 pglogical 문제 해결을 참조하세요. 자세한 내용은 PostgreSQL 문서의 논리 복제를 참조하세요.

복제할 데이터로 테이블 만들기

기본 PostgreSQL 논리 복제는 전체 데이터베이스 또는 개별 테이블만 지원합니다. 예를 들어 기본 인스턴스에 더미 테이블을 만들고 테스트할 데이터로 채워보겠습니다.

CREATE TABLE native_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO native_test (data) VALUES ('apple'), ('banana'), ('cherry');

복제본 인스턴스에도 테이블을 만들어야 합니다.

기본 인스턴스에 게시 만들기

기본 PostgreSQL 논리 복제에서는 게시자와 구독자를 다룹니다. native_test에 데이터 게시를 생성하세요.

CREATE PUBLICATION pub FOR TABLE native_test;

복제본 인스턴스에 구독 만들기

다음은 복제본 인스턴스에 구독을 만드는 예시입니다.

CREATE SUBSCRIPTION sub
    CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
    PUBLICATION pub;

복제본 인스턴스에 구독을 만들려면 cloudsqlsuperuser 역할이 필요합니다. 구독을 만든 후 native_test 테이블을 쿼리하여 데이터가 복제본 인스턴스에 표시되었는지 확인합니다.

기본 인스턴스에서 pg_replication_slots 테이블을 쿼리하여 구독에서 만든 복제 슬롯을 확인할 수 있습니다.

삭제

테스트가 성공한 후 DROP SUBSCRIPTION sub;을 사용하여 복제본에서 구독을 삭제합니다. 복제 슬롯도 기본 인스턴스에서 삭제되었는지 확인합니다. 그렇지 않으면 WAL 세그먼트가 기본 인스턴스에서 계속 누적됩니다.

기본 PostgreSQL 논리 복제에 대한 제한사항

pg_subscription 시스템 테이블의 subconninfo 열에 대한 액세스는 사용할 수 없습니다.

연결하는 사용자에게 수퍼유저 권한이 있는지 확인하므로 pg_dump를 실행해도 구독 정보를 덤프할 수 없습니다.

변경 데이터 캡처(CDC)의 디코딩된 WAL 변경사항 수신

CDC의 대체 사용 사례로서 논리 디코딩이 PostgreSQL 인스턴스에서 변경사항을 스트리밍할 수 있습니다. 여기에 사용되는 표준 도구는 pg_recvlogical입니다.

pg_recvlogical 도구를 사용하여 복제 슬롯을 만들고 해당 슬롯에서 추적되는 변경사항을 스트리밍할 수 있습니다. 변경사항 형식은 선택한 디코딩 플러그인에 따라 결정됩니다. 이 옵션은 다음과 같습니다.

wal2json: JSON 형식의 변경사항을 스트리밍합니다.
test_decoding: 베어본 텍스트 형식의 변경사항을 스트리밍합니다.

복제 슬롯 만들기

복제 슬롯을 만들려면 다음 안내를 따르세요.

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --create-slot \
  -P <decoder_plugin>

변경사항 스트리밍

하나의 Cloud Shell 터미널에서 다음을 실행합니다.

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --start \
  -f -

다른 Cloud Shell 터미널에서 데이터베이스에 연결하고 다음 명령어를 실행합니다.

CREATE TABLE cdc_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO cdc_test (data) VALUES ('apple', 'banana');
UPDATE cdc_test SET data = 'cherry' WHERE id = 2;
DELETE FROM cdc_test WHERE id = 1;
DROP TABLE cdc_test;

wal2json 디코더 플러그인을 사용하는 경우 첫 번째 Cloud Shell 터미널에 다음과 같은 출력이 표시됩니다.

{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[1,"apple"]},{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"banana"]}]}
{"change":[{"kind":"update","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"cherry"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[2]}}]}
{"change":[{"kind":"delete","schema":"public","table":"cdc_test","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[1]}}]}
{"change":[]}

test_decoding 디코더 플러그인을 사용하는 경우 첫 번째 Cloud Shell 터미널에 다음과 같은 출력이 표시됩니다.

BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464

(사용자의 트랜잭션 ID는 다를 수 있습니다.)

삭제

테스트를 완료한 후 다음을 실행하여 자신이 만든 복제 슬롯을 삭제합니다.

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --drop-slot

참고사항 및 제한사항

이 섹션의 참고사항 및 제한사항은 PostgreSQL용 Cloud SQL의 논리적 복제 및 디코딩 기능에 적용됩니다.

cloudsql.logical_decoding 또는 cloudsql.enable_pglogical이 사용 설정되어 있고 현재 논리적 복제의 게시자로 작동하는 인스턴스를 복원할 경우 먼저 모든 대상 인스턴스에 대해 복제를 사용 중지해야 합니다. 그렇지 않으면 인스턴스로 복원이 오류와 함께 실패하지만 현재 오류 세부정보가 표시되지 않습니다.
백업 시 cloudsql.logical_decoding 또는 cloudsql.enable_pglogical이 사용 설정된 인스턴스의 백업을 복원할 때, 그리고 이를 새 인스턴스로 복원할 때는 복제 상태가 새 인스턴스에 복원되지 않습니다. 이후 복제를 수동으로 다시 구성해야 합니다.
하나 이상의 Cloud SQL 읽기 복제본(물리적 복제 사용)이 있는 Cloud SQL 인스턴스에서 cloudsql.logical_decoding 또는 cloudsql.enable_pglogical을 사용 설정하면 읽기 복제본에도 해당 플래그가 사용 설정됩니다.
- Cloud SQL 읽기 복제본 인스턴스는 PostgreSQL이 읽기 복제본에서 논리적 디코딩을 지원하지 않기 때문에 논리적 복제에 대한 게시자로 작동할 수 없습니다. 그러나 승격된 경우 주 복제본을 대체할 수 있도록 읽기 복제본 인스턴스에서 플래그가 사용 설정됩니다.
- 기본 인스턴스에서 cloudsql.logical_decoding 또는 cloudsql.enable_pglogical을 사용 설정하면 모든 읽기 복제본에서 플래그가 사용 설정되며, 이는 기본 복제본과 읽기 복제본이 연속으로 다시 시작되는 원인이 됩니다. 이러한 상황을 방지하고 각 인스턴스가 다시 시작될 때 이를 제어하기 위해 (1)각 읽기 복제본에 플래그를 설정한 후 (2)기본 인스턴스에만 플래그를 설정할 수 있습니다.
- 기본 인스턴스에서 cloudsql.logical_decoding 또는 cloudsql.enable_pglogical을 사용 중지해도 모든 읽기 복제본에서 플래그가 사용 중지되지 않습니다. 인스턴스 간에 플래그를 사용 중지하려면 위에 설명된 단계와 반대로 수행해야 합니다. (1)기본 인스턴스에서 플래그를 사용 중지한 후 (2)각 읽기 복제본에서 플래그를 사용 중지하세요.