메인 콘텐츠로 건너뛰기

MySQL ClickPipe는 MariaDB를 지원합니까?

예, MySQL ClickPipe는 MariaDB 10.0 이상을 지원합니다. 구성 방식은 MySQL과 매우 유사하며, 기본적으로 GTID 복제를 사용합니다.

MySQL ClickPipe는 PlanetScale, Vitess 또는 TiDB를 지원합니까?

아니요, 이들 서비스는 MySQL의 binlog API를 지원하지 않습니다.

복제는 어떻게 관리되나요?

GTIDFilePos 복제를 모두 지원합니다. Postgres와 달리 오프셋을 관리하는 슬롯은 없습니다. 대신 MySQL 서버에 충분한 binlog 보존 기간을 설정해야 합니다. binlog 내 오프셋이 무효화되면 (예: 미러가 너무 오래 일시 중지되었거나, FilePos 복제를 사용하는 동안 데이터베이스 failover가 발생한 경우) 파이프를 resync해야 합니다. 비효율적인 쿼리로 인해 수집 속도가 느려져 보존 기간을 따라가지 못할 수 있으므로, 대상 테이블에 맞게 구체화된 뷰(Materialized View)를 최적화해야 합니다. 비활성 데이터베이스에서는 ClickPipes가 더 최근 오프셋으로 진행하지 못한 상태에서 log file이 rotate될 수도 있습니다. 정기적으로 업데이트되도록 heartbeat 테이블을 설정해야 할 수 있습니다. 초기 적재가 시작될 때 시작 지점이 되는 binlog 오프셋을 기록합니다. CDC가 계속 진행되려면 초기 적재가 완료될 때도 이 오프셋이 여전히 유효해야 합니다. 많은 양의 데이터를 수집하는 경우 적절한 binlog 보존 기간을 반드시 설정하십시오. 테이블을 설정하는 동안에는 고급 설정에서 대형 테이블에 대해 Use a custom partitioning key for initial load를 구성하면 단일 테이블을 병렬로 적재할 수 있어 초기 적재 속도를 높일 수 있습니다.

MySQL에 연결할 때 TLS 인증서 유효성 검사 오류가 발생하는 이유는 무엇인가요?

MySQL에 연결할 때 x509: certificate is not valid for any names 또는 x509: certificate signed by unknown authority와 같은 인증서 오류가 발생할 수 있습니다. 이는 ClickPipes가 기본적으로 TLS 암호화를 활성화하기 때문입니다. 이 문제를 해결하는 방법은 여러 가지가 있습니다:
  1. TLS Host 필드 설정 - 연결에 사용하는 호스트명이 인증서와 다를 때 이런 문제가 발생할 수 있습니다(AWS PrivateLink의 Endpoint Service를 사용하는 경우에 흔합니다). “TLS Host (optional)“를 인증서의 Common Name(CN) 또는 Subject Alternative Name(SAN)과 일치하도록 설정하십시오.
  2. Root CA 업로드 - 내부 인증 기관(Certificate Authority)을 사용하는 MySQL 서버나 기본 인스턴스별 CA 구성을 사용하는 Google Cloud SQL에 해당합니다. Google Cloud SQL 인증서에 액세스하는 방법에 대한 자세한 내용은 이 섹션을 참조하십시오.
  3. 서버 인증서 구성 - 서버의 SSL 인증서를 업데이트하여 모든 연결 호스트명이 포함되도록 하고, 신뢰할 수 있는 인증 기관(Certificate Authority)을 사용하십시오.
  4. 인증서 검증 건너뛰기 - 기본 구성에서 검증할 수 없는 자체 서명 인증서를 프로비저닝하는 자체 호스팅 MySQL 또는 MariaDB에 유용합니다(MySQL, MariaDB). 이 인증서를 사용하면 전송 중 데이터는 암호화되지만 서버 가장 위험이 있습니다. 운영 환경에서는 올바르게 서명된 인증서를 권장하지만, 이 옵션은 단발성 인스턴스에서 테스트하거나 레거시 인프라에 연결할 때 유용합니다.

스키마 변경도 지원합니까?

자세한 내용은 MySQL용 ClickPipes: 스키마 변경 전파 지원 페이지를 참조하십시오.

MySQL 외래 키의 캐스케이딩 삭제 ON DELETE CASCADE 복제를 지원합니까?

MySQL에서 캐스케이딩 삭제를 처리하는 방식상 이러한 삭제는 binlog에 기록되지 않습니다. 따라서 ClickPipes(또는 다른 CDC 도구)로는 이를 복제할 수 없습니다. 이로 인해 데이터 불일치가 발생할 수 있습니다. 캐스케이딩 삭제를 지원하려면 대신 트리거를 사용하는 것이 좋습니다.

점이 포함된 테이블은 왜 복제할 수 없습니까?

현재 PeerDB에는 제약이 있어 원본 테이블 식별자, 즉 스키마 이름이나 테이블 이름에 점이 포함된 경우 복제를 지원하지 않습니다. PeerDB가 점을 기준으로 분리하기 때문에, 이 경우 어느 부분이 스키마이고 어느 부분이 테이블인지 구분할 수 없습니다. 이 제약을 우회할 수 있도록 스키마와 테이블을 별도로 입력할 수 있게 지원하는 작업이 진행 중입니다.

처음에 복제 대상에서 제외한 컬럼을 나중에 포함할 수 있나요?

아직은 지원되지 않습니다. 대신 포함하려는 컬럼이 있는 테이블을 resync할 수 있습니다.
마지막 수정일 2026년 6월 10일