Schema
Describe a table on both sides and see where the two definitions disagree.
A change that cannot be applied is often a schema problem: a column exists on one side and not the other, or the two sides disagree about its type. The Schema tab describes a table on each database and lays the two descriptions against each other, so you can confirm that before reading any further into a failure.
Nothing is scanned on a schedule. A schema changes when somebody changes it, not on a clock, so every scan is something you ask for.
Asking for a scan
Each configured table gets a card with a Scan local and a Scan online button. Pressing one records a request rather than reaching out to the database directly: the agent picks the request up on its own side, describes the table, and reports back.
The button reads Waiting for agent until an answer comes back. How long that takes depends
on how the agent runs: a scheduled agent picks the request up on its next cycle, while an
agent under --watch also checks every couple of seconds during its idle gap, so a scan
usually lands almost immediately.
Each side is scanned independently. Scanning only the local side is perfectly reasonable when that is the one you doubt, though the comparison badge needs both.
An agent only describes tables it syncs
The dashboard refuses to request a scan for a table that is not configured, and the agent refuses again on its own side if asked. Neither side can be used to read the shape of an unrelated table.
Reading a card
| Shows | Meaning |
|---|---|
12 local · 12 online | How many columns each side reported |
| Not scanned yet | Neither side has been described, so the card will not open |
| Identical | Both sides were scanned and every column matches |
3 differences | Both sides were scanned and three columns disagree or are missing |
The comparison badge appears only once both sides have been scanned. One side alone tells you what that database holds, but it cannot tell you whether the other agrees.
Opening a card lists the columns in order, with each side's definition beside it.
| Column | Local | Online |
|---|---|---|
id PK | int unsigned not null auto_increment | int unsigned not null auto_increment |
remarks | varchar(150) | varchar(255) |
archived_at | datetime | — |
A definition is the type as the database itself states it, followed by nullability, any
default, and extras such as auto_increment. A dash means that side has no such column.
Rows that differ or are missing on one side are highlighted, and the primary key is tagged.
What counts as a difference
A column is counted when the two sides describe it differently — in type, nullability, default or extras — or when only one side has it at all. Column order is not compared; the list is ordered so a column missing from one side still holds its place.
Not every difference is a problem worth fixing. A wider varchar on one side will accept
everything the narrower one sends and only bites in the other direction. A column missing
entirely is the one that reliably breaks an apply, because the value has nowhere to go.
When a scan fails
A failed scan is still an answer, so the card never sits waiting forever. The reason appears beneath it in red:
- Refused: not a configured sync table — the agent was asked about a table it does not sync.
- No such table in this database — the table is configured but absent on that side, which for an
UPtable is a real finding rather than a scan problem. - Anything else is the error MySQL returned, usually a permissions problem on
INFORMATION_SCHEMA.
A rescan replaces everything stored for that side, so a table that has since been dropped shows as a failure rather than leaving its old columns behind.