Overview
How changes travel between a school's local database and the online database.
Sync Monitoring keeps two MySQL databases in agreement: the copy a school runs on-site and the copy served online. It does that with a small agent on each side and a server in the middle that holds the queue and the audit trail.
Nothing is compared table-against-table. Every change is captured the moment it happens, travels as a single queued item, and is acknowledged once the other side has written it.
The pieces
| Piece | Job |
|---|---|
| Triggers | Record every insert, update and delete into a sync_outbox table, in the same transaction as the change |
| Agent | Drains the outbox, pushes to the server, pulls the other side's changes and applies them |
| Server | Holds the queue, the cursors, the table configuration and the run history |
| Dashboard | Where you configure tables and watch for drift or stalled schools |
The agent never talks to the other database. Each side only knows its own MySQL connection and the server's URL, so the two databases need no route between them.
For the full picture — how direction is decided, what happens to a change end to end, and why every school runs on a single clock — read How it works.
What the dashboard shows
- Last seen — the agent reached the server and authenticated.
- Last sync — the last cycle that moved data.
- Row counts — each table's row count on both sides, refreshed on a slower clock, as a cheap drift check.
- Runs and logs — what each cycle pushed, applied and failed to apply.
- Conflicts — rows both databases created independently, waiting on a decision.
Get started
Sync one table, end to end, from an empty dashboard.
How it works
Direction, the journey of a change, and timing.
School configuration
Create a school and issue its token.
Sync tables
Choose what syncs, in which direction.
Schema
Compare a table's columns on both sides.
Conflicts
When both sides claim the same row.
The agent
What runs next to each database.
Installation
Get an agent running on a host.