Source Structure and Key Checks

TABLE_EXISTENCE_CHECK #

Every job table must exist in the source schema as a base table. A view or any other object is refused, named with its type, for example orders(VIEW). If the account has no privilege at all on the source schema, the schema is hidden from it, and this check fails rather than SOURCE_SELECT_PERMISSION_CHECK.

Fix: correct the table name, or point source.database at the right schema. Archive a view’s underlying table instead. On a server that stores table names in lower case, write the job’s table names in lower case.

STORAGE_ENGINE_CHECK #

Every source job table must be InnoDB. A base table whose engine is reported as NULL, usually a corrupted or unknown-engine table, is refused as <table>(<unknown>).

Fix: ALTER TABLE <table> ENGINE=InnoDB;

COLUMN_CHARSET_CHECK #

A job column the run reads or writes as text uses a character set that does not survive the utf8mb4 session exactly. In such a set two characters can read as one, or a character reads as ?: two keys then merge, and text is written back changed, while every verification passes. The check runs before any row is read:

COLUMN_CHARSET_CHECK: A job column uses a character set that GoArchive cannot read and write back
exactly through its utf8mb4 session, so keys could merge and text change without notice (tables:
[children.code(cp932) destination:notes.body(sjis)])

ENUM and SET columns are checked; numbers, temporal types, binary strings and JSON have no character set and are not. The check judges the character set, not the collation, and it runs when preflight is bypassed too.

Fix: convert the column to utf8mb4 on both servers, or leave the table out of the job. The supported and refused sets are listed under Character Sets .

Primary key checks #

GoArchive reads every table’s primary key from the database and builds all its SQL from it. The configured primary_key documents the key: it is checked against the database and never reaches a statement.

PRIMARY_KEY_CHECK #

A job table has no PRIMARY KEY, so its rows cannot be addressed.

Fix: add a PRIMARY KEY to the table.

KEY_TYPE_UNSUPPORTED #

A primary-key column cannot identify rows. Allowed key types:

• the integer types and DECIMAL;
• CHAR, VARCHAR, BINARY and VARBINARY, without a prefix length;
• DATE, DATETIME, TIMESTAMP, TIME and YEAR.

FLOAT and DOUBLE are approximate, ENUM and SET sort by their internal index, and BIT is not supported. Temporal key values must also be valid (Limitations ).

Fix: choose another root table, or leave the table out of the job.

PRIMARY_KEY_CHECK and KEY_TYPE_UNSUPPORTED run even when preflight is bypassed, because the SQL is built from the keys.

PK_COLUMN_CASE_CHECK #

The configured primary_key names the key’s columns but differs in letter case, for example log_id for LOG_ID. It is reported before PK_COLUMN_CHECK because its fix differs.

Fix: write each column exactly as the database spells it.

PK_COLUMN_CHECK #

The configured primary_key is not the table’s PRIMARY KEY: a column is missing, extra, or out of key order.

Fix: list every key column, in key order. A composite key is a list: primary_key: [order_id, line_no].

RELATION_KEY_CHECK #

Each foreign_key column must exist in its table and pair with the parent key column it references (references, by position):

• two integer types of the same signedness;
• two DECIMAL types;
• two character types with the same charset and collation;
• BINARY(n) with BINARY(n), or VARBINARY with VARBINARY;
• the same temporal type with the same fractional precision.

A nullable foreign_key column is allowed: a child row with a NULL in it matches no parent.

Fix: correct foreign_key or references, or align the column types.