Add a new component that automates DBLab full refresh using temporaryRDS/Aurora database clones created from snapshots. This enables ahassle-free data sync workflow that doesn't impact production.Features:- Create temporary RDS/Aurora clones from latest automated snapshots- Wait for clone availability with proper timeout handling- Trigger DBLab full refresh via API- Poll refresh status until completion- Clean up temporary clones automaticallyDeployment options:- AWS Lambda with SAM template and EventBridge scheduling- Standalone CLI binary for cron/manual execution- Docker container for containerized environmentsIncludes comprehensive documentation with IAM policy examplesand example configuration files.

Add a fully standalone version of the RDS/Aurora refresh tool that canbe built and deployed immediately without requiring a DBLab Enginerelease. This version has no dependencies on DBLab internal packages.The standalone component includes:- Self-contained Go module with minimal dependencies- Makefile for easy building (CLI, Lambda, Docker)- SAM template for AWS Lambda deployment- Dockerfile for container builds- Comprehensive documentationCan be used immediately by:1. go build -o rds-refresh .2. ./rds-refresh -config config.yaml

- Add UpdateSourceConfig method to update DBLab source connection  before triggering refresh, ensuring DBLab knows the clone endpoint- Add source database credentials (dbName, username, password) to  config for DBLab connection configuration- Remove Lambda-specific code, focusing on container/CLI deployment  which better suits the long-running nature of refresh operations- Remove duplicate engine-integrated code (engine/internal/rdsrefresh  and engine/cmd/rds-refresh) since standalone component is preferred- Update documentation with container deployment options (Docker,  ECS Task, Kubernetes CronJob, CLI with cron)- Update workflow to include config update step before refresh trigger

DBLab expects a flat JSON structure matching ConfigProjection fields,not a nested structure. The API automatically reloads the config afterupdate (calls reloadFn internally), so no SIGHUP is needed.Changed from nested:  {"retrieval": {"dbSource": {"host": "..."}}}To flat projection format:  {"host": "...", "port": 5432, "dbname": "...", ...}

cursorbot left a comment

The function could return success prematurely if DBLab's status stillshowed StatusFinished from a previous refresh. Since /full-refreshtriggers the operation in a goroutine, polling immediately after couldsee stale status.Now tracks whether refresh has actually started before acceptingStatusFinished as success. This prevents premature clone deletion.

…tates- Add immediate status check before ticker loop in WaitForRefreshComplete  to avoid unnecessary delay of up to pollInterval (30s) on first check- Align IsRefreshInProgress with WaitForRefreshComplete by including  StatusPending and StatusRenewed as in-progress states, preventing  potential duplicate refresh triggers

- Add problem/solution section with ASCII diagram- Add prerequisites section- Restructure quick start with numbered steps- Add configuration reference table- Simplify scheduling examples (Docker cron, K8s, ECS)- Add network requirements diagram- Add cost estimates- Improve troubleshooting section

cursorbot left a comment

- Add 'Why?' section explaining xmin horizon / bloat problem- Reduce README from ~400 to ~200 lines- Reduce CLI help from ~70 to ~40 lines- Use collapsible sections for K8s/ECS examples- Add troubleshooting table format- Focus on essential info only

- Use 'RDS clone' instead of 'clone' to avoid confusion with DBLab clones- Use 'RDS snapshot' instead of 'snapshot' to avoid confusion with DBLab snapshots- Update description: 'Perform full refresh from RDS/Aurora snapshots (logical mode)'