머신에 설치된 PeerDB. PeerDB GitHub 리포지토리의 설치 지침을 따르면 됩니다. 리포지토리를 클론한 후 docker-compose up만 실행하면 됩니다. 이 가이드에서는 PeerDB UI를 사용하며, PeerDB가 실행되면 http://localhost:3000에서 접속할 수 있습니다.
데이터베이스 객체: PeerDB는 소스 스키마를 기준으로 대상 데이터베이스에 테이블을 자동으로 생성합니다. 하지만 인덱스, 제약 조건, 트리거와 같은 일부 데이터베이스 객체는 자동으로 마이그레이션되지 않습니다. 이러한 객체는 마이그레이션 후 대상 데이터베이스에서 수동으로 다시 생성해야 합니다.
DDL 변경: 지속적 복제를 활성화하면 PeerDB는 DML 작업(INSERT, UPDATE, DELETE)에 대해 대상 데이터베이스를 소스와 동기화된 상태로 유지하고, ADD COLUMN 작업도 전파합니다. 하지만 다른 DDL 변경(예: DROP COLUMN, ALTER COLUMN)은 자동으로 전파되지 않습니다. 스키마 변경 지원에 대한 자세한 내용은 여기를 참조하십시오.
네트워크 연결: PeerDB가 실행되는 머신에서 소스 데이터베이스와 대상 데이터베이스 모두에 연결할 수 있어야 합니다. 연결을 허용하려면 방화벽 규칙이나 Security Group 설정을 구성해야 할 수 있습니다.
먼저 원본 데이터베이스와 대상 데이터베이스에 대한 피어를 각각 생성해야 합니다. 피어는 데이터베이스 연결을 나타냅니다. PeerDB UI의 사이드바에서 “Peers”를 클릭해 “Peers” 섹션으로 이동합니다. 새 피어를 생성하려면 + New peer 버튼을 클릭합니다.
마찬가지로, 필요한 연결 정보를 입력하여 ClickHouse Managed Postgres 인스턴스용 피어를 생성합니다. 인스턴스의 연결 정보는 ClickHouse Cloud 콘솔에서 확인할 수 있습니다. 정보를 모두 입력한 후 Create peer 버튼을 클릭하여 대상 피어를 저장합니다.이제 “Peers” 섹션에 소스 피어와 대상 피어가 모두 표시되는 것을 확인할 수 있습니다.
미러를 생성하면 PeerDB가 소스 데이터베이스에서 대상 데이터베이스로 초기 데이터 적재를 시작합니다. 미러를 클릭한 다음 초기 적재 탭을 클릭하면 초기 데이터 마이그레이션의 진행 상황을 모니터링할 수 있습니다.초기 적재가 완료되면 마이그레이션이 완료되었음을 나타내는 상태가 표시됩니다.
이러한 단계는 구체적인 사용 사례와 애플리케이션 요구 사항에 따라 달라질 수 있습니다. 중요한 점은 새 시스템으로 완전히 전환하기 전에 데이터 일관성을 보장하고, 다운타임을 최소화하며, 마이그레이션된 데이터의 무결성을 검증하는 것입니다.
마이그레이션이 완료된 후에는 다음을 수행하십시오:
컷오버 전 검증 확인 실행
트래픽을 전환하기 전에 원본과 대상의 주요 테이블을 비교합니다:
-- 중요 테이블의 행 수 비교SELECT 'public.orders' AS table_name, COUNT(*) AS row_count FROM public.orders;SELECT 'public.customers' AS table_name, COUNT(*) AS row_count FROM public.customers;-- 활동이 많은 테이블의 최신 레코드 점검SELECT MAX(updated_at) FROM public.orders;SELECT MAX(id) FROM public.orders;
원본 시스템의 쓰기 작업 중지
먼저 애플리케이션의 쓰기 작업을 일시 중지하십시오. 추가적인 안전장치로, cutover 중에는 원본 데이터베이스를 읽기 전용으로 설정하십시오:
ALTER DATABASE <source_db> SET default_transaction_read_only = on;
롤백이 필요한 경우 쓰기를 다시 활성화할 수 있습니다:
ALTER DATABASE <source_db> SET default_transaction_read_only = off;
복제가 완전히 동기화되었는지 확인하세요
쓰기량이 많은 하나 이상의 테이블에서 최신 행이 원본과 대상 간에 일치하는지 확인하세요:
-- 소스와 타겟 모두에서 실행하여 결과를 비교하세요SELECT MAX(id) AS latest_id, MAX(updated_at) AS latest_ts FROM public.orders;
제약 조건, 인덱스, 트리거를 다시 생성하고 활성화
수집을 위해 제약 조건이나 인덱스를 제거했거나 적용을 미뤘다면 지금 다시 적용하십시오. 또한 이전에 대상의 복제 역할을 replica로 설정했다면 이를 재설정하십시오:
ALTER ROLE <target_role> SET session_replication_role = origin;
# 예시: constraints/indexes/triggers가 포함된 SQL 파일 적용psql -h <target_host> -p <target_port> -U <target_user> -d <target_db> -f post_migration_objects.sql
대상 테이블의 시퀀스 재설정
데이터를 로드한 후 시퀀스를 현재 테이블 값에 맞춰 조정합니다:
-- 시스템 스키마를 제외한 모든 serial/identity 기반 컬럼의 시퀀스 일괄 초기화DO $$DECLARE r RECORD;BEGIN FOR r IN SELECT n.nspname AS schema_name, c.relname AS table_name, a.attname AS column_name, pg_get_serial_sequence(format('%I.%I', n.nspname, c.relname), a.attname) AS seq_name FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace JOIN pg_attribute a ON a.attrelid = c.oid WHERE c.relkind = 'r' AND a.attnum > 0 AND NOT a.attisdropped AND n.nspname NOT IN ('pg_catalog', 'information_schema') LOOP IF r.seq_name IS NOT NULL THEN EXECUTE format( 'SELECT setval(%L, COALESCE((SELECT MAX(%I) FROM %I.%I), 0) + 1, false)', r.seq_name, r.column_name, r.schema_name, r.table_name ); END IF; END LOOP;END $$;
애플리케이션 트래픽 전환
검증을 통과하고 시퀀스/제약 조건이 준비되면 다음을 수행하십시오:
읽기 트래픽을 ClickHouse Managed Postgres로 전환합니다.
쓰기 트래픽을 ClickHouse Managed Postgres로 전환합니다.
애플리케이션 오류, 제약 조건 위반, 데이터베이스 상태를 모니터링합니다.
리소스 정리
마이그레이션 결과가 만족스럽고 애플리케이션을 ClickHouse Managed Postgres를 사용하도록 전환했다면, PeerDB에서 미러와 피어를 삭제할 수 있습니다.
Replication slots지속적 복제를 활성화한 경우 PeerDB는 원본 PostgreSQL 데이터베이스에 replication slot을 생성합니다. 불필요한 리소스 사용을 방지하려면 마이그레이션을 마친 후 원본 데이터베이스에서 replication slot을 수동으로 삭제하십시오.
축하합니다! pg_dump 및 pg_restore를 사용해 PostgreSQL 데이터베이스를 ClickHouse Managed Postgres로 성공적으로 마이그레이션했습니다. 이제 Managed Postgres의 기능과 ClickHouse 통합을 살펴볼 준비가 되었습니다. 시작하는 데 도움이 되는 10분 분량의 퀵스타트 가이드는 다음과 같습니다.
