ERROR 1185 occurs when attempting binary backup operations on tables with storage engines that don't support this feature. Use mysqldump for logical backups or convert tables to InnoDB.
This error (ER_DUMP_NOT_IMPLEMENTED) indicates that the MySQL storage engine for your table does not support binary table dumps. Not all storage engines—such as MEMORY, ARCHIVE, or certain third-party engines—support binary/physical backup operations. This restriction is particularly relevant when using tools like FLUSH TABLES ... FOR EXPORT or mysqlhotcopy, which rely on the storage engine's binary dump capability.
Run this query to see what engine your table uses:
SHOW TABLE STATUS WHERE Name = 'your_table_name';Look at the Engine column. Common values: InnoDB, MyISAM, MEMORY, ARCHIVE, MERGE, FEDERATED.
For all tables in your database:
SHOW TABLE STATUS;The recommended solution is to use mysqldump, which works with all storage engines:
mysqldump -u username -p database_name > backup.sqlFor a specific table:
mysqldump -u username -p database_name table_name > table_backup.sqlThis creates a logical SQL dump that can be restored to any MySQL instance, regardless of storage engine.
If you specifically need binary dump support, convert your table to InnoDB:
ALTER TABLE table_name ENGINE=InnoDB;Verify the change:
SHOW TABLE STATUS WHERE Name = 'table_name';Note: This can be slow on large tables. Plan the conversion during low-traffic periods.
For production environments:
For InnoDB tables:
- MySQL Enterprise Backup (official)
- Percona XtraBackup (open source, highly recommended)
- mysqldump with --single-transaction for consistency
For mixed storage engines:
- mysqldump (works with everything)
- Logical backups via your application layer
Example with mysqldump and gzip compression:
mysqldump -u username -p --all-databases | gzip > full_backup.sql.gzStorage engine compatibility varies widely. MEMORY tables store data in RAM and are rebuilt from scratch on server restart, making physical backups impossible. ARCHIVE tables are designed for compression and sequential access, not binary export. If you're using third-party storage engines (like Sphinx, Connect), check their documentation for backup capabilities. For high-availability setups, consider replication instead of binary backups: set up a slave instance and back up from the slave using mysqldump with --single-transaction to avoid table locks.
EE_WRITE (3): Error writing file
How to fix "EE_WRITE (3): Error writing file" in MySQL
CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters
How to fix "CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters" in MySQL
CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed
How to fix "CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed" in MySQL
ERROR 1146: Table 'database.table' doesn't exist
How to fix "ERROR 1146: Table doesn't exist" in MySQL
ERROR 1040: Too many connections
How to fix "ERROR 1040: Too many connections" in MySQL