“Access denied; you need SUPER or SYSTEM_VARIABLES_ADMIN” on RDS import
Real error I hit importing an org
.sqldump into the AWS RDS dev database.
Running: mysql.exe ... --host=your-db.xxxxxx.ap-south-1.rds.amazonaws.com --database=app-dev < "Dump_latest....sql"
ERROR 1227 (42000) at line 24: Access denied; you need (at least one of)
the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation
Operation failed with exitcode 1
The import stopped at line 24 — before any of my tables loaded.
What actually happened
The dump was created with MySQL 8’s mysqldump, which automatically writes a
few server-control statements near the top of the file. Line 24 was:
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
Setting a GLOBAL server variable requires the SUPER (or
SYSTEM_VARIABLES_ADMIN) privilege. On a server I own, I’d have that. But this
was AWS RDS — a managed database, where Amazon deliberately withholds
SUPER so nobody can break the managed instance. So the import slammed into a
permission wall on the very first global SET.
The dump was made for a server where I’m admin, then imported into one where I’m not.
The vocabulary
| Term | What it means |
|---|---|
SUPER | The old “I can change anything on this server” MySQL privilege. RDS never grants it to your master user. |
| Binary log (binlog) | MySQL’s running diary of every change — used for replication and point-in-time backups. |
SQL_LOG_BIN | A switch to hide statements from the binlog. Setting it needs SUPER. |
| GTID | Global Transaction ID — a label MySQL uses to track transactions across replicas. |
GTID_PURGED | Tells a fresh server which GTIDs are “already applied.” Replication bookkeeping. |
The four offending lines
mysqldump had injected these privileged statements:
-- line 17
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN; -- harmless (just reads)
-- line 18
SET @@SESSION.SQL_LOG_BIN = 0; -- needs SUPER
-- line 24
SET @@GLOBAL.GTID_PURGED = ''; -- needs SYSTEM_VARIABLES_ADMIN ← the error
-- line 3282 (near end)
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN; -- needs SUPER
The fix — strip them into a clean copy
None of these touch my data — they’re binlog/replication plumbing. So I deleted those lines into a sanitized file and imported that:
sed -E '/^SET @MYSQLDUMP_TEMP_LOG_BIN/d; /^SET @@SESSION\.SQL_LOG_BIN/d; /^SET @@GLOBAL\.GTID_PURGED/d' \
"Dump_latest.sql" > "Dump_clean.sql"
# verify nothing privileged remains (should print nothing):
grep -nE "SQL_LOG_BIN|GTID_PURGED|MYSQLDUMP_TEMP_LOG_BIN" "Dump_clean.sql"
Then re-ran the import pointing at Dump_clean.sql. It went through.
What removing those lines actually affects
My data: zero impact. Not one row changed. The only real difference:
- The dump wanted the import to be invisible to the binary log
(
SQL_LOG_BIN = 0). - With that line gone, my import is written to the binlog — which is the normal default, and exactly what you want on RDS (so replicas and backups see the new data).
GTID_PURGEDwas being set to an empty string anyway, so removing it changed nothing.
SQL_LOG_BIN = 0 is a performance/cleanliness trick for admins doing bulk loads
on servers they fully own. On RDS you can’t use it and you don’t need it.
The permanent fix (generate the dump correctly)
Better than hand-cleaning every time — tell mysqldump not to write these lines:
mysqldump --set-gtid-purged=OFF --column-statistics=0 \
-h SOURCE_HOST -u USER -p DBNAME > dump.sql
--set-gtid-purged=OFF stops the GTID_PURGED line from being written at all, so
the dump imports into RDS straight away with no cleanup.
The lesson
- A managed database (RDS, Cloud SQL, Azure DB) trades root access for
reliability. Errors mentioning
SUPERalmost always mean “this statement is fine on a self-hosted server, but the managed host blocks it.” mysqldumpdefaults assume you own the destination. When the destination is managed, you must either regenerate with--set-gtid-purged=OFFor strip the global/binlog SET statements.- Always read the error’s line number and look at that exact line — it told me precisely which statement to remove.
One-line summary
ERROR 1227 ... SUPER or SYSTEM_VARIABLES_ADMINon an RDS import = the dump contains global/binlog SET statements RDS won’t allow. StripGTID_PURGED+SQL_LOG_BINlines (or dump with--set-gtid-purged=OFF). Your data is never affected — it’s replication plumbing.