fix(deploy-mining): truncate processed_cdc_events after CDC offset reset
Problem: full-reset script resets Kafka consumer offsets but doesn't clear the processed_cdc_events table. When migrations run, containers may start and consume CDC events, inserting records into this table. After offset reset, the service restarts and detects all events as "duplicates" because the idempotency records still exist. Solution: Add TRUNCATE processed_cdc_events step after CDC offset reset in Step 8, before starting services. This ensures the idempotency table is in sync with the Kafka offset position. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
parent
3591271a3b
commit
2a4cb829fe
|
|
@ -991,6 +991,17 @@ full_reset() {
|
|||
fi
|
||||
done
|
||||
|
||||
# 清空 processed_cdc_events 表(因为 migration 时可能已经消费了一些消息)
|
||||
# 这是事务性幂等消费的关键:重置 Kafka offset 后必须同时清空幂等记录
|
||||
log_info "Truncating processed_cdc_events tables to allow re-consumption..."
|
||||
for db in "rwa_contribution" "rwa_auth"; do
|
||||
if run_psql "$db" "TRUNCATE TABLE processed_cdc_events;" 2>/dev/null; then
|
||||
log_success "Truncated processed_cdc_events in $db"
|
||||
else
|
||||
log_warn "Could not truncate processed_cdc_events in $db (table may not exist yet)"
|
||||
fi
|
||||
done
|
||||
|
||||
log_step "Step 9/18: Starting 2.0 services..."
|
||||
for service in "${MINING_SERVICES[@]}"; do
|
||||
service_start "$service"
|
||||
|
|
|
|||
Loading…
Reference in New Issue