MySQL ERROR 1566 occurs when you attempt to modify binary log format settings while temporary tables are open in the session. This replication safety mechanism prevents data inconsistency between primary and replica servers. Fixing requires closing all temporary tables before changing binlog_format settings.
MySQL ERROR 1566 (ER_TEMP_TABLE_PREVENTS_SWITCH_OUT_OF_RBR) is a replication safety error that prevents changing the binary log format when temporary tables exist in the current session. The binary log format (STATEMENT, ROW, or MIXED) determines how MySQL records changes for replication. Temporary tables behave differently depending on the format: in ROW or MIXED mode, temporary table operations are not replicated; in STATEMENT mode, they are. Switching formats with open temporary tables could corrupt replication state. This error protects against situations where a temporary table created in one replication format mode could be visible in a different format after the mode changes, causing replicas to receive inconsistent instructions. MySQL enforces this restriction both at the session level (SET @@SESSION.binlog_format) and global level (SET @@GLOBAL.binlog_format or SET @@PERSIST.binlog_format).
First, identify which temporary tables are blocking the binlog_format change.
-- Check all temporary tables in the current session:
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'TEMPORARY'
AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
-- Check if replication applier threads have temporary tables:
SHOW PROCESSLIST;
-- Look for any "applier" or "SQL thread" entries, then check what they are doingTemporary tables are session-specific and disappear when the connection closes, but they persist for the duration of the session.
Close or drop all temporary tables in your current session.
-- If you know the temporary table names:
DROP TEMPORARY TABLE IF EXISTS temp_table_1, temp_table_2;
-- Or, disconnect and reconnect in a new session (cleanest approach):
-- Simply close the current MySQL connection and create a new one
-- For application code (Node.js/mysql example):
// Close the current connection
await connection.end();
// Create a new connection
const newConnection = await mysql.createConnection(config);Note: Temporary tables exist only for the current session. If you disconnect and reconnect, all temporary tables are automatically dropped.
Once all temporary tables are closed, you can safely change the binlog_format.
-- Change at SESSION level (for current connection only):
SET @@SESSION.binlog_format = 'ROW';
-- or
SET @@SESSION.binlog_format = 'STATEMENT';
-- or
SET @@SESSION.binlog_format = 'MIXED';
-- Change at GLOBAL level (requires SUPER or SYSTEM_VARIABLES_ADMIN privilege):
SET @@GLOBAL.binlog_format = 'ROW';
-- Make the change persistent across restarts (MySQL 5.7.11+, requires SUPER or SYSTEM_VARIABLES_ADMIN):
SET @@PERSIST.binlog_format = 'ROW';
-- Verify the change:
SHOW VARIABLES LIKE 'binlog_format';The change takes effect immediately for new queries in the session.
Confirm the format change and ensure replication continues working correctly.
-- Check the current binlog_format:
SHOW VARIABLES LIKE 'binlog_format';
-- Check binlog status on the primary:
SHOW MASTER STATUS;
-- On the replica, verify replication is running:
SHOW REPLICA STATUS\G
-- Or (MySQL 5.7):
SHOW SLAVE STATUS\G
-- Verify no replication lag (Seconds_Behind_Master should be 0 or small):
SHOW REPLICA STATUS\G | grep "Seconds_Behind_Master";If replication has lag, wait for it to catch up before making more changes.
For persistent global changes without runtime impact (requires restart), use PERSIST_ONLY.
-- This takes effect only after server restart, avoiding conflicts:
SET @@PERSIST_ONLY.binlog_format = 'ROW';
-- Verify it was set for next restart (check config):
SELECT * FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'binlog_format';
-- The current runtime value remains unchanged until restart:
SHOW VARIABLES LIKE 'binlog_format';PERSIST_ONLY is useful for scheduled maintenance when you want to avoid immediate replication impact.
If the error occurs on a replica when the applier thread has temporary tables, restart replication.
-- Stop the replica (MySQL 8.0.22+):
STOP REPLICA;
-- Or for older MySQL versions:
STOP SLAVE;
-- Wait a moment, then restart:
START REPLICA;
-- Or (older versions):
START SLAVE;
-- Verify replication thread status:
SHOW REPLICA STATUS\G
-- Check for errors:
SHOW REPLICA STATUS\G | grep -E "Replica_IO_Running|Replica_SQL_Running|Last_Error";This clears any residual temporary tables the applier thread was holding.
In replication scenarios, ERROR 1566 can be particularly tricky. The primary server may allow format changes, but the replica applier thread cannot if it has open temporary tables. This happens when the replica is executing statements that create temporary tables, and you attempt to change @@GLOBAL.binlog_format on the primary.
MySQL 5.7 introduced stricter enforcement of this rule. In MySQL 8.0+, the error is more likely to appear because temporary tables from complex joins and subqueries are managed more aggressively. When changing binlog_format in a multi-tier replication setup (primary → replica → cascading replica), ensure all replication channels are idle before changing the format.
For applications using connection pooling, beware: a pooled connection may retain temporary tables from previous queries. Always call DISCARD SESSION STATE or explicitly drop temporary tables before reusing a connection for format changes.
The restriction is directional: you can usually change from STATEMENT to ROW/MIXED with temporary tables present, but changing from ROW or MIXED back to STATEMENT is strictly forbidden with open temporary tables. This is because STATEMENT mode uses fewer resources for temporary tables.
If you encounter this error during a migration or upgrade, the safest approach is to accept the brief downtime of closing all client connections and restarting the MySQL server with the new binlog_format in the configuration file. This avoids runtime conflicts entirely.
ERROR 1064: You have an error in your SQL syntax
How to fix "ERROR 1064: You have an error in your SQL syntax" in MySQL
ERROR 1054: Unknown column in field list
Unknown column in field list
ER_WINDOW_RANGE_FRAME_NUMERIC_TYPE (3589): RANGE frame requires numeric ORDER BY expression
RANGE frame requires numeric ORDER BY expression in MySQL window functions
CR_ALREADY_CONNECTED (2058): Handle already connected
How to fix "CR_ALREADY_CONNECTED (2058): Handle already connected" in MySQL
ER_WINDOW_DUPLICATE_NAME (3591): Duplicate window name
How to fix ER_WINDOW_DUPLICATE_NAME (3591) in MySQL window functions