CDC 소비자가 멈춘 뒤 DB의 로그 디스크가 계속 늘어납니다. 변경 로그와 소비 위치는 어떻게 관리하나요?

CDC가 재개할 위치의 로그를 보존해야 하는 구성에서는 느리거나 중단된 소비자가 원본 로그 정리를 막을 수 있습니다. DB 쓰기가 정상이어도 디스크가 고갈될 수 있으므로 변경 생성률과 소비·보존 위치를 함께 관찰합니다.

동작 원리와 전제

PostgreSQL 복제 슬롯처럼 소비자가 요구하는 WAL 위치를 유지하는 방식은 제품별 계약을 확인합니다. 슬롯 lag와 실제 보존 바이트, 가장 오래된 위치, 사용 가능한 디스크를 봅니다. 단순 이벤트 건수만으로 로그 용량을 예측하면 큰 transaction을 놓칩니다.

선택과 실패 처리

보존 상한을 넘으면 소비자 복구가 불가능해져 스냅샷부터 다시 시작해야 할 수 있습니다. 슬롯을 삭제하면 공간을 풀 수 있지만 재개 지점을 잃으므로 먼저 소비자와 데이터 복구 계획을 확인합니다. 무조건 오래된 로그를 지우는 것은 정상 정리가 아닙니다.

구체적인 사례와 검증

원본이 초당 20MB의 로그를 만들고 소비자가 한 시간 멈추면 수십 GB의 보존 부담이 생길 수 있습니다. 실제 수치는 로그 압축·checkpoint·제품 설정에 달려 있으므로 생성 바이트와 정리 가능 위치로 계산합니다. 경보는 디스크 사용률뿐 아니라 현재 생성률에서 남은 시간도 봅니다. 소비자가 더 이상 필요하지 않은 슬롯은 소유자와 복구 요구를 확인하고 제거하지만, 운영 중인 connector의 상태를 모른 채 지우면 전체 재구축이 필요할 수 있습니다. 복구가 진행될 때도 backlog를 한꺼번에 읽어 원본과 대상 DB를 포화시키지 않도록 제한합니다.

소비 중단·복구·스냅샷 중 쓰기를 시험하고 기준 snapshot 이후 변경을 빠짐없이 이어 붙이는지 확인합니다. 원본 상태와 읽기 모델을 대조해 누락·중복을 찾습니다. CDC는 발행 유실을 줄이는 통로이지만 소비 처리·순서·최신성과 보관 비용까지 자동 해결하지 않습니다.