MySQL marks a statement unsafe for statement-based replication because it uses a fulltext parser plugin that may produce different results on replicas.
ER_BINLOG_UNSAFE_FULLTEXT_PLUGIN appears when MySQL deems a statement unsafe for statement-based replication due to a fulltext parser plugin that may act differently on replicas. Switch the source to ROW logging, install identical plugins on every node, or avoid the custom parser to resolve the error.
ER_BINLOG_UNSAFE_FULLTEXT_PLUGIN
The error appears when a DML statement that triggers a fulltext parser plugin is written to the binary log in STATEMENT format. MySQL labels the statement unsafe because the custom parser might return different tokenization results on replicas, leading to data divergence. The server therefore stops and returns Error 3006 instead of logging the query.
Replication safety matters because statement-based logging relies on deterministic results to keep master and replica tables identical. When determinism cannot be guaranteed, you must change logging strategy or remove the non-deterministic element.
The error is triggered only when binlog_format is set to STATEMENT or MIXED, and the executed statement uses MATCH...AGAINST or ALTER TABLE ... ADD FULLTEXT that relies on a user-installed parser plugin. Built-in MySQL fulltext parsing does not raise the error; only custom plugins flagged as unsafe do.
If the same plugin is not installed or compiled differently on replicas, the output can change. MySQL pre-emptively blocks the log entry to prevent silent inconsistency.
Fastest solution is to switch the source server to ROW based replication, where actual row images are logged and plugin behavior no longer matters. You can toggle it session-wide for one statement or globally.
Another fix is to install and configure the identical fulltext parser plugin on every replica so that the statement becomes deterministic. Finally, you can rewrite or avoid fulltext operations in the offending transaction if replication format cannot change.
A migration script adds a FULLTEXT index using a Chinese word-segmentation plugin with binlog_format=STATEMENT - switch to ROW first, run the DDL, then revert if desired.
An ETL job updates a table with MATCH...AGAINST using a custom parser - wrap the job in SET SESSION binlog_format='ROW' before executing, or run it on a replica not used as a replication master.
Default to ROW or MIXED with ROW fallback in modern MySQL versions. Keep plugin binaries identical and version-locked across all nodes using configuration management. Incorporate replica readiness checks that test SHOW PLUGINS before promoting a server to master.
Use Galaxy's query endorsement to document required session variables for any script that depends on custom fulltext parsing, ensuring teammates run the statement safely every time.
Error 1592 (ER_BINLOG_UNSAFE_STATEMENT) occurs when non-deterministic functions are used under STATEMENT format. The remedy is the same: switch to ROW or eliminate the non-determinism.
Error 3176 (ER_BINLOG_UNSAFE_SKIP_LOCKED) warns about SKIP LOCKED with statement logging. Consistent strategy of ROW logging and plugin parity protects against all such replication safety errors.
When the parser library exists only on the source, MySQL cannot guarantee identical tokenization on replicas and blocks the statement.
The error only rises when binlog_format is not ROW. In ROW mode, the plugin output is captured as row images, so safety checks are bypassed.
Different plugin builds or configuration options across nodes lead to potentially divergent results, making the statement unsafe.
Migrations to 5.7.1+ introduce the safety check; legacy scripts that once worked may now fail until replication format is updated.
Raised for general non-deterministic statements under STATEMENT logging.
Triggered when unsafe system variables change during a transaction.
Shows when SELECT ... SKIP LOCKED runs under statement based replication.
Ignoring it risks data divergence; always address the root cause before retrying the statement.
ROW format generates larger logs, but network and disk improvements usually offset the overhead. It is the safest mode.
Yes. Reverting to built-in fulltext parsing removes the unsafe element and the statement will replicate safely.
Galaxy lets teams share endorsed queries that include SET statements, reducing accidental runs under STATEMENT mode and preventing this error.
.avif)
.avif){kind=logo}
