Servers
Add, edit and scope the databases DBTrail captures from.
One server = one source database = one replication connection, the footprint of one replica.
Add a server
Web interface → + Add server.
The form suggests the user dbtrail and a generated password, and shows the
CREATE USER and GRANT statements with that password filled in, ready to
copy. There is no picture of the form here on purpose: a screenshot of that
block would publish a password anyone could paste and run.
| Field | Notes |
|---|---|
| Source type | MySQL, PostgreSQL (beta), MariaDB |
| Source host, port, user, password | A dedicated user; the form shows the CREATE USER and GRANT to copy |
| Schemas | Optional. Empty = every user schema. A filter cuts index size |
| Archive to S3 | Optional bucket for rotated hours: Retention |
| S3 store | Optional: S3 endpoint, S3 addressing, S3 region, S3 access key and S3 secret key, for an S3-compatible store or keys other than the daemon's. Settings belong to the bucket, so servers that share a bucket must use the same ones |
| Database, replication slot, publication | PostgreSQL only |
| Advanced | Bring your own index: host, port, user, password, index database |
Save runs preflight; a failed check becomes a card with the fix. Then an index database is provisioned and the stream starts. Test connection checks without saving, including each S3 bucket the server uses. Source requirements: prepare your MySQL source.
Getting started list
Until a new server has its first snapshot, Overview lists the steps from adding it:
- Create the index database
- Connect to the source
- Read the table structure (MySQL and MariaDB)
- Start capturing changes
- Capture the first change
- Take the first full DB snapshot. When DBTrail cannot take one yet, the step says why.
Each step is waiting, running, done or failed. A failed step shows the error and what to do. A source with no changes yet shows as running: a quiet database is normal. The list goes away once the server has a snapshot and no capture step has failed. Seeing a first change is not required: you may not want to write to production just to get started.
Local folder and S3 location are set per server on Snapshots → Settings: Backup settings.
Guards
- Duplicate source: preflight warns, without blocking, when a new server looks like a replica of one already monitored.
- One daemon per server: a per-entry lock stops double streaming.
- Restarts resume every stream from its saved checkpoint.
GTID
Recommended, especially on RDS, Aurora and Cloud SQL: binlog file names can
change after a failover, GTIDs do not. With gtid_mode = ON, capture tracks
the full executed GTID set, every backup records the set it contains, and a
whole transaction can be undone by GTID (Recovery).
Headless
Bundled Compose stack, first server from the environment:
SOURCE_DSN: user:pass@tcp(db.example.com:3306)/
SCHEMAS: shop,billing # empty = all user schemasbintrail stream by hand (start positions, GTID, TLS, gap handling):
streaming reference,
systemd units.
Stream badges: Status.