Permissions

GoArchive checks its own privileges before any data moves, and refuses a job whose account it cannot prove holds what the job needs. Grant each privilege directly to the account GoArchive connects as.

Grant recipes #

These grants pass every permission check, because each privilege is granted directly: the schema privileges on their schema, and PROCESS and REPLICATION CLIENT on *.*, the only scope they have.

Source #

GRANT SELECT, DELETE, TRIGGER ON `<source_schema>`.* TO '<user>'@'<host>';  -- DELETE, TRIGGER: archive and purge jobs
GRANT PROCESS ON *.* TO '<user>'@'<host>';                                  -- archive and purge jobs

PROCESS is server-wide by definition; there is no narrower scope for it.

Destination, with the tracking tables in the destination database (default) #

When job_schema is not set, it is destination.database, so one grant covers the data and the tracking tables:

GRANT SELECT, INSERT, CREATE, UPDATE, TRIGGER ON `<destination_schema>`.* TO '<user>'@'<host>';

Destination, with the tracking tables in a separate schema #

With destination.job_schema set, grant the two separately. A DBA creates that schema first; GoArchive never does.

GRANT SELECT, INSERT, TRIGGER ON `<destination_schema>`.* TO '<user>'@'<host>';
GRANT CREATE, SELECT, INSERT, UPDATE ON `<job_schema>`.* TO '<user>'@'<host>';

Monitored replicas (optional) #

-- On EACH server in replication.servers, for that entry's user.
GRANT REPLICATION CLIENT ON *.* TO 'monitor'@'%';

Only needed with replication.enabled: true. A server whose account lacks it holds the job rather than being skipped.

Tracking-table maintenance #

Pruning, abandoning, retiring and dropping in the tracking schema need DELETE and DROP (Tracking Table Maintenance ). GoArchive never does any of it: grant them to a DBA account, not to GoArchive’s.

Privilege matrix #

By job type. validate and dry-run need what the job’s type needs, since they run its preflight.

• Destination SELECT. Preflight proves INSERT only, and validate and dry-run never read copies. A run that verifies (sha256 or count) reads them back, and archive recovery reads them before it deletes a logged root’s tree, so an account without SELECT fails there, before any delete. Under verification: none, only archive recovery reads them. The recipes grant it.
• TRIGGER. Without TRIGGER on a table, an account sees an empty trigger list, which proves nothing, so preflight refuses the job. TRIGGER also permits creating and dropping triggers on those tables, which GoArchive never does. Granting it on each job table instead of the schema narrows it to those tables.
• CREATE on the tracking schema is needed at run time, not once: each job’s log table is created the first time the job runs. A grant without it fails at startup.
• Locks need no privilege. GoArchive’s named locks need no grant, on the source or the destination, and work on a read-only server.
• SESSION_VARIABLES_ADMIN also lets the account change other restricted session variables, so raising the server’s global max_error_count is usually the better remedy. The recipes do not include it.

The provable-grant rule #

A permission check passes only when the privilege is established for the specific table. A privilege held only through a role cannot be proven and fails as unconfirmed; so does a global grant on a server that restricts global grants with partial revokes. Grant SELECT, DELETE, INSERT, TRIGGER and the tracking-schema privileges directly to the account GoArchive connects as, at schema or table scope.

PROCESS is the exception: a role-held PROCESS is accepted, because its proof is a successful read of the foreign-key metadata, which a role-held PROCESS produces too.

How each check reports what it saw is listed under Permission, Trigger and Server Variable Checks .

Troubleshooting #

• A check lists tables you believe are granted. Check that the grant targets the account CURRENT_USER() resolves to, not the one you connected as; that it is granted directly, not through a role; and that it is on the right schema and server. Source DELETE and destination INSERT are separate grants on separate servers.
• The foreign-key visibility check fails on a schema with no cross-schema foreign keys. Expected: the check proves that the foreign-key list was complete, whatever the schema holds. Grant PROCESS.
• Least-privilege deployments. Running validate or dry-run from a more privileged account is a diagnostic only: archive, purge and copy-only run preflight again with their own accounts, which must hold every privilege their job type needs.