MySQL throws ER_TABLESPACE_CANNOT_ENCRYPT (3183, HY000) when you try to encrypt a tablespace that is not eligible for encryption.
ER_TABLESPACE_CANNOT_ENCRYPT (3183, HY000) means MySQL refused to set ENCRYPTION='Y' because the chosen tablespace is ineligible�often due to system tablespace use, innodb_file_per_table being off, or a non-InnoDB engine. Enable file-per-table or move the table to a supported InnoDB tablespace to resolve the error.
ER_TABLESPACE_CANNOT_ENCRYPT
ER_TABLESPACE_CANNOT_ENCRYPT (error 3183, SQLSTATE HY000) is raised when MySQL encounters a CREATE, ALTER, or CREATE TABLESPACE command that attempts to enable encryption on a tablespace that cannot support it.
The check was introduced in MySQL 5.7.11 to protect system tablespaces, unsupported storage engines, or server configurations where encryption is impossible. Fixing it quickly is essential for meeting compliance policies that rely on data-at-rest encryption.
The error appears when the target tablespace is the shared system tablespace, a disabled file-per-table setup, or another storage engine such as MyISAM or CSV. MySQL blocks the request because those spaces do not carry the metadata needed for per-tablespace keys.
It also triggers if a general tablespace was created without the ENCRYPTION option and you try to flip it later, or if the server is started without a keyring plugin.
First confirm that your table uses the InnoDB engine and resides in a per-table or properly created general tablespace. Then enable innodb_file_per_table and load a keyring plugin. Finally, reissue the ALTER or CREATE statement with ENCRYPTION='Y'.
Scenario 1: Table in the system tablespace. Solution: Move it to a file-per-table space and enable encryption.
Scenario 2: File-per-table disabled. Solution: Set innodb_file_per_table=ON and restart.
Scenario 3: Storage engine not InnoDB. Solution: ALTER TABLE t ENGINE=InnoDB, then encrypt.
Always run MySQL with innodb_file_per_table=ON, create new general tablespaces with ENCRYPTION='Y', and preload keyring_file or keyring_encrypted_file plugins at startup. Automate checks in your CI pipeline or use Galaxy to lint ALTER statements.
ER_TABLESPACE_EXISTS (3184) occurs if a tablespace name already exists. ER_TABLESPACE_SAME_NAME (3185) fires when you attempt to create a tablespace with the same file. Both are fixed by choosing unique names or dropping the conflicting space first.
If innodb_file_per_table is OFF, InnoDB cannot isolate the table in an encryptable .ibd file.
Tables that still live in ibdata1 are not eligible for per-tablespace encryption.
MyISAM, MEMORY, and CSV engines lack encryption metadata, triggering the error.
MySQL requires a keyring plugin (keyring_file, keyring_encrypted_file, etc.) to manage table keys.
Raised when a new tablespace duplicates an existing name. Fix by dropping or renaming the old space.
Occurs when the datafile has the same name as another tablespace file. Provide a unique filename.
Triggered when operations target a table with a discarded .ibd file. Reimport the tablespace to resolve.
Appears when you reference a nonexistent key cache while converting MyISAM tables. Create the cache or adjust the statement.
Yes, MySQL rejected the encryption request, so the tablespace remains unencrypted until you resolve the issue.
No. MySQL only supports encryption on file-per-table and properly created general tablespaces.
You must restart after changing innodb_file_per_table or loading keyring plugins, but most ALTER statements can run online afterward.
Galaxy's editor flags unsupported ENCRYPTION clauses and suggests fixes before you run the SQL, preventing runtime failures.
.avif)
.avif){kind=logo}
