Purging Data

The purge workflow removes data from the source without copying it anywhere. It uses the same discovery and ordering as the other workflows, so related rows are removed together and in the correct order.

Running it #

goarchive purge -c archiver.yaml --job archive_old_orders

When to use it #

• Completing a two-step archive — the data was already copied with the copy workflow, and now the source can be cleared.
• Clearing data that does not need keeping — expired sessions, processed queues, obsolete test data.
• Removing a related set cleanly, where a plain DELETE would be rejected because other tables still reference the rows.

What happens #

GoArchive discovers the rows belonging to each batch of root rows exactly as it does elsewhere, then removes them children-first. Because nothing is copied, there is no copy step and no verification step.

Progress is recorded per batch, so an interrupted purge resumes rather than restarts.

Before running #

Purge removes data. Preview the job first:

goarchive dry-run -c archiver.yaml --job archive_old_orders

The preview shows the filter being applied and how many rows each table would contribute. Read those numbers before running the purge, and make sure you have a current backup.

Pacing removals #

Purge runs generate a steady stream of deletions. Two settings control the pace:

processing:
  batch_delete_size: 500       # rows per delete operation
  delete_sleep_seconds: 0.5    # pause between delete operations

Lower the size and raise the pause when replicas need to keep up.

Tables with triggers #

As with archiving, a trigger that fires on deletion is reported and requires explicit confirmation:

goarchive purge -c archiver.yaml --job archive_old_orders --force-triggers