<p>MySQL raises ER_BINLOG_UNSAFE_SYSTEM_TABLE when a statement that touches general_log, slow_log, or performance_schema tables is written to the binary log, because replicas may not have identical system tables.</p>
<p>MySQL Error 1670: ER_BINLOG_UNSAFE_SYSTEM_TABLE signals that a statement touching general_log, slow_log, or performance_schema tables cannot be safely written to the binary log, risking replication drift. Disable binlogging for the session or rewrite the query to avoid those system tables to fix the issue.</p>
The statement is unsafe because it uses the general log,
MySQL throws this error when a statement that modifies or selects from system logging tables would be recorded in the binary log. Because replicas may store these tables differently, logging such statements could break deterministic replication.
The server blocks the statement and returns SQLSTATE HY000 to prevent replication mismatches. Understanding why the table is unsafe is the first step toward remediation.
System tables like general_log, slow_log, and performance_schema are local to each node. They can be enabled, disabled, or truncated independently. Writing them to the binlog means replicas might replay statements that do not apply or collide with their own settings, leading to divergent states.
The error appears during INSERT, UPDATE, DELETE, CREATE TABLE AS SELECT, or SELECT ... INTO OUTFILE statements that reference one of the flagged system tables while binary logging is enabled and binlog_format is STATEMENT or MIXED.
Ignoring the warning and forcing the statement through can corrupt replication, cause replication lag, or require time-consuming re-syncs. Addressing it early protects data integrity across the cluster.
INSERT or CREATE TABLE AS SELECT commands that move diagnostic data into permanent tables will trigger the error when binary logging is on.
Reading or joining performance_schema tables inside multi-table statements can be flagged as unsafe because result sets differ per server.
Many applications rely on default STATEMENT mode. Any statement using system tables under this format is automatically marked unsafe.
TRUNCATE TABLE general_log or DROP TABLE performance_schema.* operations are blocked to avoid wiping log data only on replicas.
Raised when a statement is unsafe in MIXED mode for reasons other than system tables.
Occurs when non-deterministic auto-increment behavior makes statement logging unsafe.
Triggered when logging cannot proceed due to missing privileges or disk space.
SET GLOBAL sql_log_bin = 0 requires SUPER or SYSTEM_VARIABLES_ADMIN, but ignoring the error risks replica divergence.
Yes, ROW format logs exact row images, so system table differences do not matter. Ensure the change does not impact performance.
Turning off sql_log_bin only for a session or statement does not affect global binary logs or incremental backup strategies.
Galaxy highlights system table usage and suggests setting binlog_format to ROW or disabling binlog before execution, reducing human error.
.avif)
.avif){kind=logo}
