Permission, Trigger and Server Variable Checks

Permission checks #

SOURCE_SELECT_PERMISSION_CHECK, SOURCE_DELETE_PERMISSION_CHECK, DEST_WRITE_PERMISSION_CHECK and JOB_SCHEMA_PERMISSION_CHECK each pass only when the privilege is provable for the object (the provable-grant rule ). Three states fail, and the message names the state:

Table-scoped checks name TABLE(state), for example orders(unconfirmed). JOB_SCHEMA_PERMISSION_CHECK names PRIVILEGE(state), for example CREATE(unconfirmed), because it tests four privileges on one schema. Each fix is a grant recipe .

SOURCE_SELECT_PERMISSION_CHECK #

The source account needs SELECT on every job table. It runs for every job type.

SOURCE_DELETE_PERMISSION_CHECK #

The source account needs DELETE on every job table of an archive or purge job. validate and dry-run check it too, so a missing grant is caught before a run has copied anything.

DEST_WRITE_PERMISSION_CHECK #

The destination account needs INSERT on every job table. Verification also needs destination SELECT, which this check does not prove, so grant both.

JOB_SCHEMA_PERMISSION_CHECK #

The destination account needs CREATE, SELECT, INSERT and UPDATE on the tracking schema (destination.job_schema, by default the destination database). CREATE is needed at run time: each job’s log table is created the first time the job runs. The message names the grant, and CREATE DATABASE when CREATE is missing, since GoArchive never creates the schema:

JOB_SCHEMA_PERMISSION_CHECK: destination account lacks provable CREATE, UPDATE on tracking
schema "goarchive" (states: CREATE(unconfirmed), UPDATE(unconfirmed)). Grant each missing
privilege directly to the account at schema scope (DBA must: CREATE DATABASE `goarchive`;
GRANT CREATE, UPDATE ON `goarchive`.* TO <user>)

Trigger checks #

DELETE_TRIGGER_VISIBILITY_CHECK #

The source account of an archive or purge job cannot be proven to see a job table’s triggers, so an empty list of DELETE triggers proves nothing. The message names each table with its state.

Fix: grant TRIGGER directly to the account at schema or table scope. A role-held TRIGGER stays unconfirmed. --force-triggers does not apply: it accepts triggers preflight can list, never a list it cannot trust.

DELETE_TRIGGER_CHECK #

A source table of an archive or purge job has a DELETE trigger. GoArchive cannot see what it does, and its side effects are outside the archive and its verification.

Override: --force-triggers, on archive, purge, validate and dry-run, accepts the triggers this check lists; they then fire on every delete. Audit them first.

Server variable checks #

MAX_ALLOWED_PACKET_CHECK #

Every key-addressed statement (the copy read, verification, delete chunks, discovery by foreign_key, and the tracking log’s statements) carries at most its statement cap of keys, and at most batch_size; the source’s by-key statements carry at most the larger of batch_size and batch_delete_size. Preflight sizes each statement at that many keys, counting the statement text and the bound values as they travel. If one exceeds a server’s max_allowed_packet, which GoArchive reads from each server, the run is refused before any row is read; without the check it would fail mid-run.

The message names the server, the statement, the table and the bytes needed, and the remedies that fit:

• raise max_allowed_packet to at least that size;
• lower batch_size or batch_delete_size to the largest count that fits;
• for a statement at its cap, lower range_optimizer_max_mem_size (set it, when it is 0) to shrink the cap.

INSERTs carry rows, not keys, and are not bounded here: large values are sent separately, so what can still fail an INSERT is one value larger than the destination’s packet, or rarely the whole statement (Limitations ).