How to fix ERROR 1105: Unknown error in MySQL

The generic "Unknown error" message hides the real cause in the error log. First, find the error log location:

SHOW VARIABLES LIKE 'log_error';

Then check the error log file with details about what failed:

# On Linux/macOS
tail -100 /var/log/mysql/error.log

# Or follow it in real-time
tail -f /var/log/mysql/error.log

Look for stack traces, plugin crash messages, or other specific errors near the timestamp of your Error 1105. The detailed message will point you toward the actual problem (plugin crash, corruption, etc.). Copy relevant error lines and search for solutions based on the specific message, not the generic 1105 code.

Table corruption can trigger Error 1105. Check and repair the affected tables:

-- Check table integrity
CHECK TABLE table_name;

-- If errors are found, repair the table
REPAIR TABLE table_name;

For multiple tables in a database:

mysqlcheck -u root -p database_name --repair

If the table uses InnoDB (not MyISAM), try a safe repair with innodb_ruby or dump and restore:

# Dump the table
mysqldump -u root -p database_name table_name > table_backup.sql

# Drop and restore
mysql -u root -p database_name < table_backup.sql

Run the failing query again after repairs to see if the error is resolved.

After upgrading MySQL, plugins compiled for an older version may crash with Error 1105. Check loaded plugins:

SHOW PLUGINS;

Identify any custom or third-party plugins. Verify they support your MySQL version by checking their documentation. If incompatible:

1. Uninstall the plugin:

UNINSTALL PLUGIN plugin_name;

2. Recompile or upgrade the plugin for your MySQL version

3. Reinstall it:

INSTALL PLUGIN plugin_name SONAME 'plugin_library.so';

For user-defined functions (UDFs), check that they are compiled for your MySQL version and architecture (32-bit vs 64-bit). Recompile if necessary:

gcc -fPIC -shared -o my_udf.so my_udf.c -I/usr/include/mysql

Then reinstall in MySQL and test again.

Insufficient disk space or memory can cause unexpected failures. Check available resources:

# Check disk space
df -h /var/lib/mysql

# Check memory
free -h

# Check MySQL memory usage
top

If disk is low, free up space immediately:

# Clean old binary logs (if no replication)
mysql -u root -p -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"

# Remove temporary files
rm -rf /var/lib/mysql/tmp/*

If memory is constrained, increase available memory or reduce MySQL buffer pool:

[mysqld]
innodb_buffer_pool_size = 2G  # Adjust based on available RAM

After freeing resources, restart MySQL and retry the failing query:

sudo systemctl restart mysql

If Error 1105 started after a configuration change, revert it:

# View your MySQL configuration file
cat /etc/mysql/my.cnf
# or
cat /etc/my.cnf

Look for recent changes to:
- innodb_buffer_pool_size (set too high can cause memory issues)
- max_connections (too high causes resource exhaustion)
- sql_mode (incompatible settings with certain operations)
- Custom plugin options

If you made changes, revert them:

# Backup current config
cp /etc/mysql/my.cnf /etc/mysql/my.cnf.backup

# Revert to previous version from backup
cp /etc/mysql/my.cnf.old /etc/mysql/my.cnf

Restart MySQL:

sudo systemctl restart mysql

Test if the error is resolved. If it is, gradually reintroduce changes in a test environment to find the problematic setting.

Reproduce the error consistently to narrow down the cause:

# Export the query to a test script
echo "SELECT * FROM problematic_table LIMIT 1;" > test_query.sql

# Run it with verbose logging to capture error details
mysql -u root -p --verbose database_name < test_query.sql 2>&1 | tee query_result.log

For replication failures:

-- Check replica status
SHOW REPLICA STATUS\G

-- If stuck on a specific event, skip it
SET GLOBAL SQL_REPLICA_SKIP_COUNTER = 1;
START REPLICA;

-- Monitor progress
SHOW REPLICA STATUS\G

Run the query in isolation with minimal load to confirm it fails consistently. If it only fails under load, the issue is resource-related (see Step 4).