Career OS

“Access denied; you need SUPER or SYSTEM_VARIABLES_ADMIN” on RDS import

Real error I hit importing an org .sql dump 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

TermWhat it means
SUPERThe 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_BINA switch to hide statements from the binlog. Setting it needs SUPER.
GTIDGlobal Transaction ID — a label MySQL uses to track transactions across replicas.
GTID_PURGEDTells 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_PURGED was 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 SUPER almost always mean “this statement is fine on a self-hosted server, but the managed host blocks it.”
  • mysqldump defaults assume you own the destination. When the destination is managed, you must either regenerate with --set-gtid-purged=OFF or 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_ADMIN on an RDS import = the dump contains global/binlog SET statements RDS won’t allow. Strip GTID_PURGED + SQL_LOG_BIN lines (or dump with --set-gtid-purged=OFF). Your data is never affected — it’s replication plumbing.

Saves your progress on this device.