체크포인트로 안전하게 시스템을 맞추는 증분 데이터 동기화

전체 재임포트가 계속 문제를 일으키는 이유

전체 재임포트는 단순해 보여서 안전하다고 느껴집니다: 삭제, 다시 로드, 끝. 하지만 실제로는 느린 동기화, 비용 증가, 엉킨 데이터가 생기는 가장 쉬운 방법 중 하나입니다.

첫 번째 문제는 시간과 비용입니다. 매번 전체 데이터셋을 가져오면 같은 레코드를 계속 다시 다운로드합니다. 예를 들어 밤마다 50만 명의 고객을 동기화한다면 변경된 레코드가 200개뿐이어도 컴퓨트, API 호출, 데이터베이스 쓰기 비용을 지불하게 됩니다.

두 번째 문제는 정확성입니다. 전체 재임포트는 매칭 규칙이 완전하지 않으면 중복을 만들거나(예: 이메일 대소문자, 전화번호 포맷 차이), 내보낸 데이터에 있던 오래된 값으로 최신 수정을 덮어써 버릴 수 있습니다. 많은 팀이 "삭제 후 재로드"가 중간에 조용히 실패하면서 합계가 시간이 지나며 달라지는 것을 보기도 합니다.

일반적인 증상은 다음과 같습니다:

• 실행 후 시스템 간 카운트가 일치하지 않음
• 작은 차이(이메일 대소문자, 전화 포맷)로 레코드가 두 번 나타남
• 최근에 업데이트된 필드가 오래된 값으로 되돌아감
• 동기화가 "완료"된 것처럼 보이지만 데이터 일부를 놓침
• 임포트 창 이후로 고객지원 티켓이 급증

체크포인트는 단순히 "여기까지 처리했다"라고 저장한 작은 마커입니다. 다음 번에는 그 마커부터 계속하면 됩니다. 마커는 타임스탬프, 레코드 ID, 버전 번호, API가 반환한 토큰 등일 수 있습니다.

장기적으로 두 시스템을 정렬 상태로 유지하는 것이 목표라면, 체크포인트를 사용한 증분 데이터 동기화가 보통 더 나은 선택입니다. 데이터 변경이 잦거나, 내보내기 파일이 크거나, API에 속도 제한이 있거나, 작업이 중간에 실패했을 때 안전하게 재개해야 할 경우 특히 유용합니다 (예: AppMaster 같은 플랫폼에서 내부 도구로 만든 작업이 도중에 실패할 때).

방법을 선택하기 전에 동기화 목표 정의하기

체크포인트를 사용하는 증분 동기화는 "올바름"이 무엇인지 명확할 때 잘 작동합니다. 이것을 건너뛰고 바로 커서나 해시로 뛰어들면 규칙이 문서화되지 않아 나중에 동기화를 재설계하게 되는 경우가 많습니다.

먼저 시스템을 명명하고 누가 진실의 출처인지 결정하세요. 예를 들어 CRM은 고객 이름과 전화번호의 소스 오브 트루스이고, 청구 도구는 구독 상태의 소스 오브 트루스일 수 있습니다. 동일한 필드를 양쪽에서 수정할 수 있다면 단일 소스 오브 트루스가 없으므로 충돌 처리를 계획해야 합니다.

다음으로 "정렬된 상태"가 무엇인지 정의하세요. 항상 정확히 일치해야 하나요, 아니면 몇 분 내에 업데이트가 반영되면 괜찮나요? 정확한 일치는 더 엄격한 순서 보장, 체크포인트에 대한 강한 보장, 삭제 처리에 더 신중함을 요구합니다. 결국 일관성(eventual consistency)은 보통 비용이 적게 들고 일시적 실패에 관대합니다.

동기화 방향도 결정하세요. 단방향 동기화는 단순합니다: 시스템 A가 시스템 B로 데이터를 보냅니다. 양방향 동기화는 더 어렵습니다. 각 업데이트가 충돌이 될 수 있고, 양쪽이 서로를 계속 "수정"하는 끝없는 루프를 피해야 합니다.

구축 전에 답해야 할 질문들

모두가 동의하는 간단한 규칙을 문서화하세요:

• 각 필드(또는 오브젝트 유형)에 대한 진실의 소스는 어느 시스템인가?
• 허용 가능한 지연 시간은 얼마인가(초, 분, 시간)?
• 이것은 단방향인가 양방향인가, 각 방향으로 어떤 이벤트가 흐르는가?
• 삭제는 어떻게 처리되는가(하드 삭제, 소프트 삭제, 톰스톤)?
• 양쪽에서 같은 레코드를 변경했을 때 어떻게 되는가?

실용적인 충돌 규칙은 "구독 필드는 billing 우선, 연락처 필드는 CRM 우선, 그 외에는 최신 업데이트 우선"처럼 간단할 수 있습니다. AppMaster 같은 도구로 통합을 구축한다면 이러한 규칙을 Business Process 로직에 캡처해 두어 누군가의 기억에만 남지 않게 하고 테스트 가능하도록 하세요.

커서, 해시, 재개 토큰: 구성 요소

체크포인트를 사용하는 증분 동기화는 보통 안전하게 저장하고 재사용할 수 있는 세 가지 유형의 "위치" 중 하나에 의존합니다. 어떤 것을 선택할지는 소스 시스템이 보장할 수 있는 것과 어떤 실패를 견뎌야 하는지에 달려 있습니다.

커서 체크포인트는 가장 단순합니다. 마지막으로 처리한 것(예: 마지막 ID, last updated_at 타임스탬프, 시퀀스 번호)을 저장합니다. 다음 실행 때 그 지점 이후의 레코드를 요청합니다. 소스가 일관되게 정렬되고 ID나 타임스탬프가 신뢰할 수 있게 앞으로만 갈 때 잘 작동합니다. 그러나 업데이트가 늦게 도착하거나 시계가 달라지거나 과거에 레코드가 삽입되는(예: 백필) 경우에는 깨질 수 있습니다.

해시는 커서만으로 부족할 때 변경을 감지하는 데 도움이 됩니다. 관심 있는 필드를 기반으로 각 레코드를 해시해 해시가 바뀔 때만 동기화하거나, 배치 전체를 해시해 드리프트를 빠르게 확인한 후 세부 항목을 조사할 수 있습니다. 레코드별 해시는 정확하지만 저장 및 계산 비용이 들고, 배치 해시는 저렴하지만 어떤 항목이 변경되었는지를 숨길 수 있습니다.

재개 토큰은 종종 페이징이나 이벤트 스트림을 위해 소스가 발행하는 불투명 값입니다. 해석하지 않고 저장했다가 다시 전달해 이어가면 됩니다. API가 복잡할 때 토큰은 훌륭하지만 만료되거나 보존 기간 이후에 무효가 되거나 환경에 따라 다르게 동작할 수 있습니다.

무엇을 사용해야 하고 무엇이 잘못될 수 있는가

• 커서: 빠르고 단순하지만 순서가 뒤바뀌는 업데이트에 주의하세요.
• 레코드별 해시: 정확한 변경 감지지만 비용이 더 듭니다.
• 배치 해시: 드리프트 신호로 저렴하지만 구체성이 낮습니다.
• 재개 토큰: 페이징에 가장 안전하지만 만료되거나 일회성일 수 있습니다.
• 하이브리드(커서 + 해시): updated_at가 완전히 신뢰할 수 없을 때 흔히 사용됩니다.

AppMaster 같은 도구로 동기화를 구축하면 이러한 체크포인트는 보통 작은 "sync state" 테이블에 저장되어 매 실행마다 추측 없이 재개할 수 있습니다.

체크포인트 저장소 설계

체크포인트 저장소는 체크포인트를 사용하는 증분 동기화를 신뢰할 수 있게 만드는 작은 부분입니다. 읽기 어렵거나 쉽게 덮어쓸 수 있거나 특정 작업에 묶여 있지 않다면, 동기화는 한 번 실패할 때까지는 괜찮아 보이다가 이후에는 추측으로 운영하게 됩니다.

먼저, 체크포인트를 어디에 둘지 선택하세요. 데이터베이스 테이블이 보통 가장 안전합니다. 트랜잭션, 감사, 간단한 쿼리를 지원하기 때문입니다. 이미 사용 중이고 원자 업데이트를 지원한다면 키-값 스토어도 괜찮습니다. 구성 파일은 단일 사용자이거나 위험이 낮은 동기화에만 적합합니다. 잠그기 어렵고 잃어버리기 쉽기 때문입니다.

무엇을 저장할 것인가(그리고 이유)

체크포인트는 단순한 커서 이상입니다. 디버그, 재개, 드리프트 감지를 위해 충분한 컨텍스트를 저장하세요:

• 작업 식별: 작업 이름, 테넌트 또는 계정 id, 오브젝트 타입(예: customers)
• 진행 상황: 커서 값 또는 재개 토큰, 그리고 커서 타입(시간, id, token)
• 상태 신호: 마지막 실행 시간, 상태, 읽은 레코드 수와 기록된 레코드 수
• 안전성: 마지막 성공 커서(시도한 마지막 커서가 아니라), 그리고 최신 실패에 대한 짧은 오류 메시지

변경 감지 해시를 사용한다면 해시 방법의 버전도 저장하세요. 그렇지 않으면 나중에 해시를 변경했을 때 모든 것을 "변경됨"으로 잘못 취급할 수 있습니다.

버전 관리와 다수의 동기화 작업

데이터 모델이 변경되면 체크포인트에 버전을 부여하세요. 가장 쉬운 방법은 schema_version 필드를 추가하고 새 버전에 대해 기존 행을 변경하지 않고 새 행을 만드는 것입니다. 롤백을 위해 옛 행을 잠시 보관하세요.

여러 동기화 작업이 있을 경우 네임스페이스를 명확히 하세요. 좋은 키는 (tenant_id, integration_id, object_name, job_version)입니다. 이렇게 하면 두 작업이 하나의 커서를 공유해 조용히 데이터를 건너뛰는 고전적인 버그를 피할 수 있습니다.

구체적 예: 내부 도구를 AppMaster에서 만들 경우, PostgreSQL에 테넌트와 오브젝트별로 한 행씩 체크포인트를 저장하고 배치 커밋이 성공된 후에만 업데이트하세요.

단계별: 증분 동기화 루프 구현하기

증분 체크포인트 동기화는 루프가 단조롭고 예측 가능할 때 가장 잘 작동합니다. 목표는 단순합니다: 안정된 순서로 변경을 읽고, 안전하게 기록한 다음, 쓰기가 완료되었음을 알 때만 체크포인트를 앞으로 옮기는 것입니다.

신뢰할 수 있는 단순 루프

먼저 같은 레코드에 대해 절대 변하지 않는 정렬 기준을 선택하세요. 타임스탬프는 작동할 수 있지만 동점 해소를 위한 식별자(ID)를 포함해야 두 업데이트가 같은 시간일 때 순서가 뒤섞이지 않습니다.

그다음 루프를 다음과 같이 실행하세요:

• 커서(예: last_updated + id)와 페이지 크기를 결정합니다.
• 저장된 체크포인트보다 최신인 다음 페이지의 레코드를 가져옵니다.
• 각 레코드를 대상에 업서트(없으면 생성, 있으면 업데이트)하고 실패를 캡처합니다.
• 성공한 쓰기를 커밋한 뒤, 마지막으로 처리한 레코드에서 새로운 체크포인트를 영구 저장합니다.
• 반복합니다. 페이지가 비어 있으면 잠시 대기한 후 다시 시도합니다.

체크포인트 업데이트를 페치와 분리해 두세요. 체크포인트를 너무 일찍 저장하면 크래시가 발생했을 때 데이터를 조용히 건너뛸 수 있습니다.

중복 없이 백오프와 재시도

호출은 실패할 수 있다고 가정하세요. 페치나 쓰기가 실패하면 짧은 백오프(예: 1초, 2초, 5초)와 최대 재시도 횟수로 재시도하세요. 업서트와 같은 방법으로 재시도를 안전하게 만드세요. 같은 입력이면 같은 결과가 나오는 방식으로 작업하세요.

작은 실전 예: 고객 업데이트를 1분마다 동기화한다면 한 번에 200건을 가져와 업서트하고, 그 다음에 마지막 고객의 (updated_at, id)를 새 커서로 저장할 수 있습니다.

AppMaster에서 구축하면 체크포인트를 간단한 테이블(Data Designer)에 모델링하고, Business Process에서 페치, 업서트, 체크포인트 업데이트를 하나의 통제된 흐름으로 실행할 수 있습니다.

재개를 안전하게 만들기: 멱등성과 원자적 체크포인트

동기화가 재개 가능하면 최악의 시점에서 재개됩니다: 타임아웃, 크래시, 부분 배포 이후 등입니다. 목표는 단순합니다: 같은 배치를 다시 실행해도 중복을 만들거나 업데이트를 잃지 않아야 합니다.

멱등성은 안전망입니다. 같은 작업을 반복해도 최종 결과가 바뀌지 않도록 작성하세요. 실제로는 보통 insert가 아닌 업서트를 사용합니다: 안정적인 키(customer_id 같은)를 사용해 기록하고, 이미 존재하면 업데이트합니다.

좋은 "쓰기 키"는 재시도 중에도 신뢰할 수 있어야 합니다. 일반적 옵션은 소스 시스템의 자연 ID나 처음 본 순간 저장한 합성 키입니다. 데이터베이스의 고유 제약으로 지원하면 두 작업자가 경쟁할 때도 규칙이 강제됩니다.

원자적 체크포인트도 똑같이 중요합니다. 데이터를 커밋하기 전에 커서를 앞으로 옮기면 크래시 때문에 레코드를 영원히 건너뛸 수 있습니다. 체크포인트 업데이트를 쓰기 작업과 같은 작업 단위로 처리하세요.

증분 동기화의 간단한 패턴:

• 마지막 체크포인트(커서나 토큰) 이후 변경을 읽습니다.
• 중복 제거 키를 사용해 각 레코드를 업서트합니다.
• 트랜잭션을 커밋합니다.
• 그제야 새로운 체크포인트를 저장합니다.

순서가 뒤바뀌거나 늦게 도착하는 데이터도 흔한 함정입니다. 어떤 레코드는 10:01에 업데이트됐지만 10:02의 레코드보다 늦게 도착할 수 있습니다. 또는 API가 재시도 시 더 오래된 변경을 전달할 수 있습니다. 소스의 "last_modified"를 저장하고 "마지막 쓰기 우선(last write wins)" 규칙을 적용해 들어오는 레코드가 기존보다 최신일 때만 덮어쓰도록 보호하세요.

더 강한 보호가 필요하면 작은 오버랩 창(예: 마지막 몇 분을 재읽음)을 유지하고 멱등 업서트로 반복을 무시하세요. 약간의 추가 작업이 들지만 재개가 지루해지도록 만들어야 합니다. 그게 바로 목표입니다.

AppMaster에서는 같은 아이디어를 Business Process 흐름으로 깔끔하게 표현할 수 있습니다: 먼저 업서트 로직을 실행하고 커밋한 후 최종 단계로 커서나 재개 토큰을 저장하세요.

증분 동기화를 망치는 흔한 실수들

대부분의 동기화 버그는 코드 문제가 아닙니다. 현실 데이터가 나오기 전까지는 안전해 보이는 몇 가지 가정에서 옵니다. 체크포인트 기반 증분 동기화를 안정적으로 유지하려면 초기에 다음 덫들을 주의하세요.

흔한 실패 지점

updated_at을 너무 믿는 것이 흔한 실수입니다. 일부 시스템은 백필, 타임존 수정, 일괄 편집 또는 읽기-수정 과정에서 타임스탬프를 다시 쓸 수 있습니다. 커서가 단순히 타임스탬프이면 레코드를 놓치거나(타임스탬프가 뒤로 점프) 거대한 범위를 재처리할 수 있습니다(타임스탬프가 앞으로 점프).

또 다른 함정은 ID가 연속적이거나 엄격히 증가한다고 가정하는 것입니다. 임포트, 샤딩, UUID, 삭제된 행 등은 이 가정을 깨뜨립니다. "마지막으로 본 ID"를 체크포인트로 사용하면 갭과 순서가 뒤바뀐 쓰기로 인해 레코드가 남겨질 수 있습니다.

가장 해로운 버그는 부분 성공에서 체크포인트를 전진시키는 것입니다. 예: 1,000건을 페치해 700건만 쓰고 크래시가 발생했는데도 페치에서 얻은 "다음 커서"를 저장하면 재개 시 나머지 300건은 다시 시도되지 않습니다.

삭제도 무시하기 쉽습니다. 소스는 소프트 삭제(플래그), 하드 삭제(행 제거), 또는 "게시 취소"(상태 변경)를 할 수 있습니다. 활성 레코드만 업서트하면 대상이 천천히 달라집니다.

마지막으로 스키마 변경이 옛 해시를 무효화할 수 있습니다. 해시가 특정 필드 집합에서 만들어졌다면 필드를 추가하거나 이름을 바꾸면 "변경 없음"이 "변경됨"으로 보이거나 그 반대로 될 수 있습니다. 해시 로직에 버전을 두세요.

더 안전한 기본값은 다음과 같습니다:

• 가능한 경우 원시 타임스탬프보다 단조 증가하는 커서(이벤트 ID, 로그 위치)를 선호하세요.
• 체크포인트 쓰기를 데이터 쓰기와 동일한 성공 경계로 취급하세요.
• 삭제를 명시적으로 추적하세요(톰스톤, 상태 전환 또는 주기적 조정).
• 해시 입력에 버전을 부여하고 이전 버전을 읽을 수 있게 유지하세요.
• 소스가 업데이트 순서를 바꿀 수 있다면 작은 오버랩 창(마지막 N 항목 재읽기)을 추가하세요.

AppMaster에서 이 작업을 하면 체크포인트를 Data Designer의 별도 테이블로 모델링하고 "데이터 쓰기 + 체크포인트 쓰기" 단계를 한 번의 Business Process 실행으로 묶어 재시도 시 작업이 건너뛰어지지 않도록 할 수 있습니다.

시끄럽지 않은 모니터링과 드리프트 감지

체크포인트 기반 증분 동기화의 좋은 모니터링은 "로그를 더 많이 쌓는" 것이 아니라 매 실행마다 신뢰할 수 있는 몇 가지 숫자를 갖는 것입니다. "우리가 무엇을 처리했는가, 얼마나 걸렸는가, 어디서 재개할 것인가"를 답할 수 있다면 대부분의 문제를 몇 분 내에 디버그할 수 있습니다.

매 실행마다 하나의 간결한 실행 기록을 남기세요. 일관되게 유지하면 실행을 비교해 추세를 찾을 수 있습니다.

• 시작 커서(또는 재개 토큰)와 끝 커서
• 가져온 레코드 수, 기록된 레코드 수, 건너뛴 레코드 수
• 실행 시간 및 레코드당(또는 페이지당) 평균 시간
• 오류 수와 상위 오류 원인
• 체크포인트 쓰기 상태(성공/실패)

드리프트 감지는 다음 레이어입니다: 시스템이 "둘 다 작동 중"이지만 서서히 어긋나는 경우를 알려줍니다. 단순한 합계는 오해를 불러일으킬 수 있으므로 가벼운 합계 확인과 작은 샘플 검사 조합을 사용하세요. 예: 하루에 한 번 활성 고객 총수를 양쪽 시스템에서 비교한 다음, 랜덤 고객 ID 20개를 샘플로 골라 몇 개의 핵심 필드(상태, updated_at, 이메일)를 확인합니다. 합계가 다르지만 샘플이 일치하면 삭제나 필터 누락일 가능성이 있고, 샘플이 다르면 변경 감지 해시나 필드 매핑이 잘못되었을 가능성이 큽니다.

알림은 드물고 실행 가능한 것이어야 합니다. 간단한 규칙: 사람이 지금 당장 조치해야 할 경우에만 경보를 발생시키세요.

• 커서가 멈춤(끝 커서가 N회 실행 동안 이동하지 않음)
• 오류율 상승(예: 1% → 5% 한 시간 동안)
• 실행 시간이 평소 상한을 초과
• 백로그 증가(새 변경이 동기화 속도보다 빠르게 도착)
• 드리프트 확인(연속 두 번의 검사에서 합계 불일치)

실패 후에는 수동 정리 없이 재실행하세요. 가장 쉬운 방법은 마지막으로 커밋된 체크포인트에서 재개하는 것입니다. 작은 오버랩 창을 사용한다면(마지막 페이지를 재읽음) 업서트를 멱등하게 만들어 반복을 무시하세요. AppMaster에서는 이러한 검사를 Business Process 흐름으로 구현하고 이메일/SMS 또는 Telegram 모듈로 알림을 보내 실패가 대시보드 없이도 보이게 합니다.

배포 전 빠른 체크리스트

증분 체크포인트 동기화를 프로덕션에 켜기 전에 보통 늦은 놀라움을 일으키는 몇 가지를 빠르게 점검하세요. 이 체크는 몇 분이면 끝나지만 기록 누락 디버깅에 며칠을 줄여줍니다.

실용적인 사전 배포 체크리스트:

• 정렬에 사용할 필드(타임스탬프, 시퀀스, ID)가 정말 안정적이고 소스 쪽에 인덱스가 있는지 확인하세요. 나중에 변경될 수 있다면 커서가 흐려집니다.
• 업서트 키가 고유함을 보장하는지, 두 시스템이 동일하게 처리하는지(대소문자, 트리밍, 포맷)를 확인하세요. 한쪽이 "ABC"를 저장하고 다른 쪽이 "abc"를 저장하면 중복이 생깁니다.
• 각 작업과 각 데이터셋에 대해 체크포인트를 별도로 저장하세요. "글로벌 마지막 커서"는 간단해 보이지만 두 테이블, 두 테넌트, 두 필터를 동기화하면 깨집니다.
• 소스가 결국 일관성(eventually consistent)을 제공한다면 작은 오버랩 창을 추가하세요. 예: "last_updated = 10:00:00"에서 재개할 때 09:59:30부터 다시 시작하고 멱등 업서트를 통해 반복을 무시합니다.
• 가벼운 조정 계획: 일정에 따라 작은 샘플 집합(예: 랜덤 100건)을 골라 주요 필드를 비교해 조용한 드리프트를 잡아내세요.

현실성 테스트: 실행을 중간에 일시 중지하고 재시작해 같은 결과가 나오는지 확인하세요. 재시작으로 카운트가 변하거나 추가 행이 생기면 출시에 앞서 수정하세요.

AppMaster에서 동기화를 구축한다면 각 통합 흐름의 체크포인트 데이터를 특정 프로세스와 데이터셋에 묶어 관련 없는 자동화와 공유하지 마세요.

예: 두 앱 간 고객 레코드 동기화

간단한 설정을 상상해 보세요: CRM이 연락처의 진실의 출처이고, 동일한 사람들이 고객지원 도구나 고객 포털에도 존재하도록 하려는 상황입니다.

첫 실행에서는 일회성 임포트를 수행하세요. 예: updated_at과 동점 해소용 id로 안정된 순서로 연락처를 가져옵니다. 각 배치를 대상에 기록한 후 last_updated_at과 last_id 같은 체크포인트를 저장하세요. 그 체크포인트가 이후 모든 실행의 시작점입니다.

지속적 실행에서는 체크포인트보다 최신인 레코드만 가져옵니다. 업데이트는 간단합니다: CRM 연락처가 이미 있으면 대상 레코드를 업데이트하고, 없으면 생성하세요. 병합은 까다롭습니다. CRM은 종종 중복을 병합하면서 한 연락처를 "승자"로 남깁니다. 이를 비활성으로 표시하거나 승자에 매핑하도록 처리해 포털에 동일한 사람의 계정이 두 개 생기지 않도록 하세요.

삭제는 일반적으로 "업데이트 이후" 쿼리에 잘 안 나오므로 대비하세요. 일반적 옵션은 소스의 소프트-삭제 플래그, 별도의 "삭제된 연락처" 피드, 또는 주기적인 경량 조정으로 누락된 ID를 확인하는 것입니다.

실패 사례: 동기화가 중간에 크래시했다면 체크포인트를 끝에만 저장하면 큰 범위를 다시 처리해야 합니다. 대신 배치당 재개 토큰을 사용하세요.

• 실행을 시작하고 run_id(재개 토큰)를 생성합니다.
• 배치를 처리하고 대상 변경을 기록한 다음 run_id에 연결된 체크포인트를 원자적으로 저장합니다.
• 재시작 시 해당 run_id의 마지막 저장된 체크포인트를 감지하고 거기서 계속합니다.

성공은 지루하게 보입니다: 일일 카운트가 안정적이고 실행 시간이 예측 가능하며 동일한 창을 다시 실행해도 예상치 못한 변경이 전혀 없습니다.

다음 단계: 패턴을 선택하고 재작업 없이 구축하기

첫 번째 증분 루프가 작동하면 재작업을 피하는 가장 빠른 방법은 동기화 규칙을 문서화하는 것입니다. 짧게 유지하세요: 범위에 포함되는 레코드, 충돌 시 우선 필드, 각 실행이 "완료"되었을 때의 상태.

작게 시작하세요. 하나의 데이터셋(예: customers)을 골라 엔드투엔드로 실행해 보세요: 초기 임포트, 증분 업데이트, 삭제, 의도적 실패 후 재개. 다섯 개 테이블을 더 추가한 뒤 가정들을 고치는 것보다 지금 수정하는 것이 쉽습니다.

전체 재빌드는 여전히 가끔 옳은 선택입니다. 체크포인트 상태가 손상되었거나 식별자가 바뀌었거나 스키마 변경으로 변경 감지 로직이 깨졌을 때(예: 해시를 사용했고 필드 의미가 바뀐 경우) 재빌드를 검토하세요. 재빌드를 할 때는 비상 버튼이 아니라 통제된 작업으로 처리하세요.

안전한 재임포트 방법:

• 그림자 테이블이나 병렬 데이터셋으로 임포트해 현재 것은 계속 라이브로 둡니다.
• 카운트를 검증하고 null, 병합 레코드 같은 엣지 케이스를 샘플링해 확인합니다.
• 관계를 백필한 다음 계획된 컷오버로 리더를 새 데이터셋으로 전환합니다.
• 롤백을 위한 짧은 보관 기간 후에 옛 데이터셋을 정리합니다.

코드를 쓰지 않고 이것을 만들고 싶다면 AppMaster가 도와줄 수 있습니다: Data Designer로 PostgreSQL에 데이터를 모델링하고, Business Process Editor에서 동기화 규칙을 정의하며, 스케줄된 작업으로 레코드를 가져와 변환하고 업서트하세요. AppMaster는 요구사항 변경 시 깔끔한 코드를 재생성해 "한 필드 더 추가"가 덜 위험해지도록 합니다.

데이터셋을 더 확장하기 전에 동기화 계약을 문서화하고 하나의 패턴(커서, 재개 토큰 또는 해시)을 선택해 하나의 동기화를 완전히 신뢰할 수 있게 만드세요. 그런 다음 동일한 구조를 다음 데이터셋에 반복하세요. 빠르게 시도해보고 싶다면 AppMaster에서 애플리케이션을 생성하고 작은 예약 동기화 작업을 먼저 실행해 보세요.