트랜잭션 롤백도 ClickHouse에 복제되나요?
ClickHouse에 데이터를 원본 Postgres보다 더 오래 보관할 수 있습니까?
Postgres에서 ClickHouse로 전송되는 데이터를 어떻게 보강할 수 있습니까?
여러 Postgres 인스턴스에서 하나 이상의 ClickHouse 서비스로 복제할 수 있습니까?
유휴 상태 전환이 Postgres CDC ClickPipe에 어떤 영향을 미치나요?
ClickPipes for Postgres에서 TOAST 컬럼은 어떻게 처리됩니까?
ClickPipes for Postgres에서 생성 컬럼은 어떻게 처리되나요?
Postgres CDC에 포함되려면 테이블에 기본 키가 있어야 합니까?
- Primary Key: 가장 간단한 방법은 테이블에 기본 키를 정의하는 것입니다. 이렇게 하면 각 행을 고유하게 식별할 수 있어 업데이트 및 삭제를 추적하는 데 매우 중요합니다. 이 경우 REPLICA IDENTITY를
DEFAULT(기본 동작)로 설정할 수 있습니다.
- Replica Identity: 테이블에 기본 키가 없는 경우 replica identity를 설정할 수 있습니다. replica identity는
FULL로 설정할 수 있으며, 이 경우 변경 사항을 식별할 때 전체 행이 사용됩니다. 또는 테이블에 고유 인덱스가 있는 경우 해당 인덱스를 사용하도록 설정한 뒤 REPLICA IDENTITY를 USING INDEX index_name으로 설정할 수도 있습니다.
replica identity를 FULL로 설정하려면 다음 SQL 명령을 사용할 수 있습니다:
ALTER TABLE your_table_name REPLICA IDENTITY FULL;
REPLICA IDENTITY FULL을 사용하면 성능에 영향을 미칠 수 있으며 WAL도 더 빠르게 증가할 수 있다는 점에 유의하십시오. 특히 기본 키가 없고 업데이트나 삭제가 자주 발생하는 테이블에서는 각 변경 사항마다 더 많은 데이터가 기록되어야 하므로 이러한 영향이 더 크게 나타날 수 있습니다. 테이블의 기본 키 또는 레플리카 아이덴티티 설정과 관련해 확신이 없거나 도움이 필요하면 지원 팀에 문의하여 안내를 받으십시오.
또한 기본 키나 레플리카 아이덴티티가 모두 정의되어 있지 않으면 ClickPipes는 해당 테이블의 변경 사항을 복제할 수 없으며, 복제 과정에서 오류가 발생할 수 있다는 점도 유의해야 합니다. 따라서 ClickPipe를 설정하기 전에 테이블 스키마를 검토하고 이러한 요구 사항을 충족하는지 확인하는 것이 좋습니다.
Postgres CDC에서 파티션된 테이블도 지원합니까?
공개 IP가 없거나 프라이빗 네트워크에 있는 Postgres 데이터베이스에 연결할 수 있나요?
-
SSH 터널링
- 대부분의 사용 사례에 적합합니다
- 설정 방법은 여기를 참조하세요
- 모든 리전에서 사용할 수 있습니다
-
AWS PrivateLink
- 다음 3개의 AWS 리전에서 사용할 수 있습니다:
- us-east-1
- us-east-2
- eu-central-1
- 자세한 설정 방법은 PrivateLink 문서를 참조하세요
- PrivateLink를 사용할 수 없는 리전에서는 SSH 터널링을 사용하세요
UPDATE와 DELETE는 어떻게 처리하나요?
_peerdb_ 버전 컬럼 사용)을 가진 새 행으로 캡처합니다. ReplacingMergeTree 테이블 엔진은 순서 지정 키(ORDER BY 컬럼)를 기준으로 백그라운드에서 주기적으로 중복 제거를 수행하며, 가장 최신 _peerdb_ 버전의 행만 유지합니다.
Postgres의 DELETE는 삭제된 것으로 표시된 새 행(_peerdb_is_deleted 컬럼 사용)으로 전파됩니다. 중복 제거 프로세스는 비동기적으로 수행되므로 일시적으로 중복이 보일 수 있습니다. 이를 해결하려면 쿼리 계층에서 중복 제거를 처리해야 합니다.
또한 기본적으로 Postgres는 DELETE 작업 중 기본 키 또는 replica identity에 포함되지 않은 컬럼 값은 전송하지 않습니다. DELETE 시 전체 행 데이터를 캡처하려면 REPLICA IDENTITY를 FULL로 설정할 수 있습니다.
자세한 내용은 다음 문서를 참조하십시오:
PostgreSQL에서 기본 키 컬럼을 업데이트할 수 있습니까?
기본적으로 PostgreSQL의 기본 키 업데이트는 ClickHouse에서 제대로 재현할 수 없습니다.이러한 제한이 있는 이유는 ReplacingMergeTree의 중복 제거가 ORDER BY 컬럼(일반적으로 기본 키에 해당)을 기준으로 동작하기 때문입니다. PostgreSQL에서 기본 키가 업데이트되면 ClickHouse에서는 기존 행이 업데이트되는 것이 아니라 다른 키를 가진 새 행으로 표시됩니다. 그 결과, 이전 기본 키 값과 새 기본 키 값이 모두 ClickHouse 테이블에 존재할 수 있습니다.
ClickPipes for Postgres CDC 비용은 얼마입니까?
replication slot 크기가 계속 커지거나 줄어들지 않습니다. 원인이 무엇인가요?
-
데이터베이스 활동의 급격한 증가
- 대규모 배치 업데이트, 대량 삽입, 또는 큰 폭의 스키마 변경은 짧은 시간에 많은 WAL 데이터를 생성할 수 있습니다.
- replication slot은 이러한 WAL 레코드가 소비될 때까지 보관하므로, 크기가 일시적으로 급증할 수 있습니다.
-
장시간 실행되는 트랜잭션
- 트랜잭션이 열린 상태로 유지되면 Postgres는 해당 트랜잭션이 시작된 이후 생성된 모든 WAL 세그먼트를 보관해야 하므로, 슬롯 크기가 크게 증가할 수 있습니다.
- 트랜잭션이 무기한 열린 상태로 남지 않도록
statement_timeout 및 idle_in_transaction_session_timeout을 적절한 값으로 설정하십시오:
SELECT
pid,
state,
age(now(), xact_start) AS transaction_duration,
query AS current_query
FROM
pg_stat_activity
WHERE
xact_start IS NOT NULL
ORDER BY
age(now(), xact_start) DESC;
-
유지 관리 또는 유틸리티 작업(예:
pg_repack)
pg_repack 같은 도구는 전체 테이블을 재작성하여 짧은 시간에 많은 양의 WAL 데이터를 생성할 수 있습니다.- 이러한 작업은 트래픽이 적은 시간대에 예약하거나, 실행 중에는 WAL 사용량을 면밀히 모니터링하십시오.
-
VACUUM 및 VACUUM ANALYZE
- 이러한 작업은 데이터베이스 상태 유지에 필요하지만, 특히 큰 테이블을 스캔할 경우 추가적인 WAL 트래픽을 생성할 수 있습니다.
- autovacuum 튜닝 매개변수를 사용하거나, 수동 VACUUM 작업을 사용량이 적은 시간대에 예약하는 방안을 고려하십시오.
-
복제 소비자가 슬롯을 적극적으로 읽고 있지 않음
- CDC 파이프라인(예: ClickPipes) 또는 다른 복제 소비자가 중지되거나, 일시 중지되거나, 비정상 종료되면 WAL 데이터가 슬롯에 누적됩니다.
- 파이프라인이 지속적으로 실행 중인지 확인하고, 연결 또는 인증 오류가 있는지 로그를 점검하십시오.
이 주제를 더 깊이 이해하려면 다음 블로그 게시물을 확인해 보십시오: Overcoming Pitfalls of Postgres Logical Decoding.
Postgres 데이터 타입은 ClickHouse에 어떻게 매핑되나요?
Postgres에서 ClickHouse로 데이터를 복제할 때 사용자 정의 데이터 타입 매핑을 정의할 수 있나요?
Postgres의 JSON 및 JSONB 컬럼은 어떻게 복제되나요?
- sync의 경우 중간에 취소되면 Postgres의 confirmed_flush_lsn이 앞으로 진행되지 않으므로, 다음 sync는 중단된 작업과 동일한 위치에서 시작하여 데이터 일관성을 보장합니다.
- normalize의 경우 ReplacingMergeTree의 삽입 순서가 중복 제거를 처리합니다.
요약하면, 일시 중지 중에는 sync 및 normalize 프로세스가 종료되지만, 데이터 손실이나 불일치 없이 다시 재개할 수 있으므로 안전합니다.
ClickPipe 생성은 자동화할 수 있나요, 아니면 API나 CLI로 수행할 수 있나요?
초기 적재 속도를 높이려면 어떻게 해야 하나요?
snapshot number of tables in parallel 값을 늘리거나, 큰 테이블에 대해 인덱스가 있는 사용자 지정 파티셔닝 컬럼을 지정할 수 있습니다.
복제를 설정할 때 publication 범위는 어떻게 설정해야 합니까?
REPLICA IDENTITY FULL이 설정되어 있는지 확인하십시오. 기본 키가 없는 테이블이 있을 때 모든 테이블을 대상으로 publication을 생성하면 해당 테이블에서 DELETE 및 UPDATE 작업이 실패합니다.
데이터베이스에서 기본 키가 없는 테이블을 식별하려면 다음 쿼리를 사용할 수 있습니다.
SELECT table_schema, table_name
FROM information_schema.tables
WHERE
(table_catalog, table_schema, table_name) NOT IN (
SELECT table_catalog, table_schema, table_name
FROM information_schema.table_constraints
WHERE constraint_type = 'PRIMARY KEY') AND
table_schema NOT IN ('information_schema', 'pg_catalog', 'pgq', 'londiste');
-
기본 키가 없는 테이블을 ClickPipes에서 제외:
기본 키가 있는 테이블만 포함되도록 publication을 생성합니다:
CREATE PUBLICATION clickpipes_publication FOR TABLE table_with_primary_key1, table_with_primary_key2, ...;
-
기본 키가 없는 테이블을 ClickPipes에 포함:
기본 키가 없는 테이블을 포함하려면 해당 테이블의 replica identity를
FULL로 변경해야 합니다. 이렇게 하면 UPDATE 및 DELETE 작업이 올바르게 수행됩니다:
ALTER TABLE table_without_primary_key1 REPLICA IDENTITY FULL;
ALTER TABLE table_without_primary_key2 REPLICA IDENTITY FULL;
CREATE PUBLICATION clickpipes_publication FOR TABLE <...>, <...>;
ClickPipes가 관리하도록 두는 대신 publication을 직접 생성하는 경우에는 FOR ALL TABLES publication을 생성하지 않는 것이 좋습니다. 이렇게 하면 파이프에 포함되지 않은 다른 테이블의 변경 사항까지 전송되어 Postgres에서 ClickPipes로의 트래픽이 늘고, 전체 효율도 떨어집니다.publication을 수동으로 생성하는 경우에는 파이프에 추가하기 전에 원하는 테이블을 먼저 publication에 추가하십시오.
Postgres 읽기 레플리카 또는 핫 대기 인스턴스에서 복제하는 경우에는 기본 인스턴스에 직접 publication을 생성해야 하며, 이 publication은 대기 인스턴스로 자동 전파됩니다. 대기 인스턴스에서는 publication을 생성할 수 없으므로, 이 경우 ClickPipe가 publication을 관리할 수 없습니다.
권장 max_slot_wal_keep_size 설정
- 최소 기준:
max_slot_wal_keep_size를 최소 2일치 WAL 데이터를 보관하도록 설정하십시오.
- 대규모 데이터베이스(트랜잭션 볼륨이 높은 환경): 하루 최대 WAL 생성량의 2~3배 이상을 보관하십시오.
- 스토리지 제약이 있는 환경: 복제 안정성을 유지하면서 디스크가 부족해지지 않도록 이 값을 보수적으로 조정하십시오.
적절한 설정값을 산정하려면 WAL 생성 속도를 측정하십시오:
PostgreSQL 10 이상
SELECT pg_wal_lsn_diff(pg_current_wal_insert_lsn(), '0/0') / 1024 / 1024 AS wal_generated_mb;
PostgreSQL 9.6 이하 버전:
SELECT pg_xlog_location_diff(pg_current_xlog_insert_location(), '0/0') / 1024 / 1024 AS wal_generated_mb;
- 위 쿼리를 하루 중 여러 시간대에 실행하고, 특히 트랜잭션이 매우 많은 시간대에 실행하십시오.
- 24시간 동안 생성되는 WAL 양을 계산하십시오.
- 충분한 보존 기간을 확보할 수 있도록 해당 값에 2 또는 3을 곱하십시오.
max_slot_wal_keep_size를 MB 또는 GB 단위의 계산된 값으로 설정하십시오.
예시
데이터베이스에서 하루에 100 GB의 WAL이 생성된다면 다음과 같이 설정하세요:
max_slot_wal_keep_size = 200GB
로그에 ReceiveMessage EOF 오류가 표시됩니다. 무슨 의미입니까?
ReceiveMessage는 Postgres 논리 디코딩(logical decoding) protocol에서 복제 스트림의 메시지를 읽는 함수입니다. EOF(End of File) 오류는 복제 스트림을 읽는 도중 Postgres 서버와의 연결이 예기치 않게 종료되었음을 의미합니다.
이 오류는 복구 가능한 오류이며, 전혀 치명적이지 않습니다. ClickPipes는 자동으로 다시 연결을 시도하고 복제 프로세스를 재개합니다.
다음과 같은 몇 가지 이유로 발생할 수 있습니다.
- 네트워크 문제: 일시적인 네트워크 중단으로 인해 연결이 끊어질 수 있습니다.
- Postgres 서버 재시작: Postgres 서버가 재시작되거나 비정상 종료되면 연결이 끊어집니다.
replication slot이 무효화되었습니다. 어떻게 해야 하나요?
max_slot_wal_keep_size 설정값이 너무 낮기 때문입니다(예: 수 GB). 이 값을 늘리는 것을 권장합니다. max_slot_wal_keep_size 조정 방법은 이 섹션을 참조하세요. 이상적으로는 replication slot 무효화를 방지하기 위해 최소 200GB로 설정해야 합니다.
드문 경우지만 max_slot_wal_keep_size가 구성되지 않았는데도 이 문제가 발생하는 사례가 있었습니다. 이는 PostgreSQL의 복잡하고 드문 버그 때문일 수 있지만, 정확한 원인은 아직 명확하지 않습니다.
ClickPipe가 데이터를 수집하는 동안 ClickHouse에서 메모리 부족(OOM)이 발생합니다. 도와주실 수 있습니까?
-
LEFT JOIN의 오른쪽 테이블이 매우 큰 경우에 사용할 수 있는 일반적인 JOIN 최적화 기법이 있습니다. 이 경우 쿼리를 RIGHT JOIN으로 재작성하고 더 큰 테이블을 왼쪽으로 옮기십시오. 그러면 쿼리 플래너가 메모리를 더 효율적으로 사용할 수 있습니다.
-
JOIN의 또 다른 최적화 방법은 subqueries 또는 CTEs를 사용해 테이블을 명시적으로 필터링한 다음, 이 서브쿼리들 사이에서 JOIN을 수행하는 것입니다. 이렇게 하면 플래너가 행을 효율적으로 필터링하고 JOIN을 수행하는 데 도움이 되는 힌트를 얻을 수 있습니다.
초기 적재 중 invalid snapshot identifier가 표시됩니다. 어떻게 해야 하나요?
invalid snapshot identifier 오류는 ClickPipes와 Postgres 데이터베이스 간 연결이 끊어질 때 발생합니다. 이는 게이트웨이 timeout, 데이터베이스 재시작, 또는 기타 일시적인 문제로 인해 발생할 수 있습니다.
초기 적재가 진행 중일 때는 Postgres 데이터베이스에서 업그레이드나 재시작처럼 서비스에 영향을 줄 수 있는 작업을 수행하지 말고, 데이터베이스에 대한 네트워크 연결이 안정적으로 유지되도록 하는 것이 좋습니다.
이 문제를 해결하려면 ClickPipes UI에서 resync를 트리거할 수 있습니다. 그러면 초기 적재 프로세스가 처음부터 다시 시작됩니다.
Postgres에서 publication을 삭제하면 어떻게 되나요?
- Postgres에서 동일한 이름과 필요한 테이블로 새 publication을 생성합니다
- ClickPipe의 설정 탭에서 ‘Resync tables’ 버튼을 클릭합니다
이 resync가 필요한 이유는 이름이 같더라도 다시 생성한 publication이 Postgres에서 다른 객체 식별자(OID)를 갖기 때문입니다. resync 프로세스는 대상 테이블을 갱신하고 연결을 복원합니다.
원하는 경우 완전히 새 파이프를 생성할 수도 있습니다.
또한 파티션된 테이블로 작업 중이라면 적절한 설정으로 publication을 생성해야 합니다.
CREATE PUBLICATION clickpipes_publication
FOR TABLE <...>, <...>
WITH (publish_via_partition_root = true);
Unexpected Datatype 오류 또는 Cannot parse type XX ...가 표시되면 어떻게 해야 하나요?
복제/슬롯 생성 중 invalid memory alloc request size <XXX>와 같은 오류가 발생합니다
소스 Postgres 데이터베이스에서 데이터가 삭제되더라도 ClickHouse에 전체 이력 기록을 유지해야 합니다. ClickPipes에서 Postgres의 DELETE 및 TRUNCATE 작업을 완전히 무시할 수 있습니까?
CREATE PUBLICATION <pub_name> FOR TABLES IN SCHEMA <schema_name> WITH (publish = 'insert,update');
초기 적재가 완료되었지만 ClickHouse에 데이터가 없거나 일부가 누락되었습니다. 원인은 무엇인가요?
- 사용자에게 원본 테이블을 읽을 수 있는 충분한 권한이 있는지 확인합니다.
- ClickHouse 측에 행을 필터링하는 행 정책이 있는지 확인합니다.
ClickPipe에서 failover가 활성화된 replication slot을 생성할 수 있습니까?
Advanced Settings 섹션에서 아래 스위치를 켜면 ClickPipes가 failover가 활성화된 replication slot을 생성할 수 있습니다. 이 기능을 사용하려면 Postgres 버전이 17 이상이어야 합니다.
소스가 이에 맞게 구성되어 있으면 Postgres 읽기 레플리카로 failover된 후에도 슬롯이 유지되므로 데이터 복제가 중단 없이 계속됩니다. 자세한 내용은 여기를 참조하십시오.
Internal error encountered during logical decoding of aborted sub-transaction와 같은 오류가 발생합니다
ReorderBufferPreserveLastSpilledSnapshot 루틴에서 발생한다는 점을 보면, logical decoding이 디스크에 spill된 snapshot을 읽지 못하는 것으로 보입니다. logical_decoding_work_mem 값을 더 크게 늘려 보십시오.
CDC 복제 중 error converting new tuple to map 또는 error parsing logical message와 같은 오류가 발생합니다
처음에 복제에서 제외한 컬럼을 포함할 수 있나요?
ClickPipe가 Snapshot 상태에 들어갔는데 데이터가 유입되지 않습니다. 무엇이 문제일 수 있나요?
병렬 스냅샷에서 파티션을 가져오는 데 시간이 걸립니다
replication slot 생성이 트랜잭션 잠금으로 차단됩니다
CREATE_REPLICATION_SLOT 쿼리가 Lock 상태에 머물러 있는 것을 확인할 수 있습니다. 이는 Postgres가 replication slot을 생성할 때 사용하는 객체에 대해 다른 트랜잭션이 잠금을 보유하고 있기 때문일 수 있습니다.
차단 중인 쿼리를 확인하려면 Postgres 소스에서 아래 쿼리를 실행하십시오:
SELECT
blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query,
blocking.state AS blocking_state
FROM pg_locks blocked_lock
JOIN pg_stat_activity blocked
ON blocked_lock.pid = blocked.pid
JOIN pg_locks blocking_lock
ON blocking_lock.locktype = blocked_lock.locktype
AND blocking_lock.database IS NOT DISTINCT FROM blocked_lock.database
AND blocking_lock.relation IS NOT DISTINCT FROM blocked_lock.relation
AND blocking_lock.page IS NOT DISTINCT FROM blocked_lock.page
AND blocking_lock.tuple IS NOT DISTINCT FROM blocked_lock.tuple
AND blocking_lock.virtualxid IS NOT DISTINCT FROM blocked_lock.virtualxid
AND blocking_lock.transactionid IS NOT DISTINCT FROM blocked_lock.transactionid
AND blocking_lock.classid IS NOT DISTINCT FROM blocked_lock.classid
AND blocking_lock.objid IS NOT DISTINCT FROM blocked_lock.objid
AND blocking_lock.objsubid IS NOT DISTINCT FROM blocked_lock.objsubid
AND blocking_lock.pid != blocked_lock.pid
JOIN pg_stat_activity blocking
ON blocking_lock.pid = blocking.pid
WHERE NOT blocked_lock.granted;
