MySQL error 1598 occurs when the server cannot write to the binary log, usually due to transaction isolation level conflicts with statement-based logging or filesystem permission issues. Fixing it requires changing the binary log format or transaction isolation level.
MySQL error 1598 (ER_BINLOG_LOGGING_IMPOSSIBLE) indicates that MySQL server is unable to write the binary log. This is a critical error because binary logs are essential for replication, point-in-time recovery, and backup consistency. The most common cause is a conflict between your configured binary log format and the transaction isolation level being used. When you use statement-based binary logging (binlog_format=STATEMENT) with READ-COMMITTED or READ-UNCOMMITTED isolation levels on InnoDB tables, the same statement can produce different results on the replica than on the source server, making replication unsafe. A secondary set of causes relates to filesystem issues: permissions preventing the MySQL daemon from writing binlog files, insufficient disk space, or incorrect paths configured after an upgrade.
Connect to MySQL and verify the current settings:
SHOW GLOBAL VARIABLES LIKE 'binlog_format';
SHOW GLOBAL VARIABLES LIKE 'transaction_isolation';This will show you if there's a conflict. If you see STATEMENT format with READ-COMMITTED or READ-UNCOMMITTED isolation, that's the problem.
For persistent changes, edit your MySQL configuration file (/etc/mysql/my.cnf or /etc/my.cnf):
[mysqld]
binlog_format = ROWThen restart MySQL:
sudo systemctl restart mysql
# or on systems using mysqld_safe:
sudo mysqld_safeROW-based logging is safer for replication with all isolation levels. It logs the actual row changes rather than the SQL statement, preventing consistency issues.
If you need to change immediately without restarting (for new connections only):
SET GLOBAL binlog_format = 'ROW';If you prefer automatic format switching, MIXED mode uses statement-based logging by default but switches to row-based for unsafe statements:
[mysqld]
binlog_format = MIXEDThen restart MySQL. MIXED format provides a good balance but may cause larger binary logs than pure ROW format.
If you're using a READ-COMMITTED or READ-UNCOMMITTED isolation level, consider changing to REPEATABLE-READ:
SET GLOBAL transaction_isolation = 'REPEATABLE-READ';This setting takes effect for new connections. Existing connections retain their previous isolation level.
If you still see the error after configuration changes, verify the MySQL daemon can write to the datadir:
# Find the datadir location
mysql -u root -p -e "SHOW VARIABLES LIKE 'datadir';"
# Check ownership and permissions (replace /var/lib/mysql with your datadir)
ls -ld /var/lib/mysql
ls -la /var/lib/mysql/mysql-bin.*
# Fix ownership if needed (MySQL 8.0+)
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysqlIn Docker/Kubernetes environments, ensure the volume is mounted with mysql (uid 999 or similar) ownership:
docker run -d \
-v /path/to/volume:/var/lib/mysql \
mysql:latestIf the binary log cannot be created at startup, verify free disk space:
df -h /var/lib/mysql
# If full, rotate existing logs to free space
mysql -u root -p -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);"
# Or disable binary logging if recovery/replication isn't needed
# Add to my.cnf:
# skip-log-bin
# Then restart MySQLAlways test your configuration file syntax before restarting:
mysqld --validate-configThis catches syntax errors and prevents startup failures. Look for "mysqld: ready for connections" in the output.
Binary Log Format Trade-offs:
Statement-based (STATEMENT): Smaller log files but unsafe with certain isolation levels. Not recommended for replication.
Row-based (ROW): Larger logs but safest for replication and works with all isolation levels. Recommended for most setups.
Mixed (MIXED): Automatically switches formats. Good compromise but can be unpredictable.
InnoDB Specific:
InnoDB with READ-COMMITTED isolation level requires ROW-based logging due to gap locking and phantom reads. The MySQL server actively prevents STATEMENT format with this combination.
Replication Considerations:
If you're using GTIDs (Global Transaction Identifiers) for replication and disable binary logging after an abnormal shutdown, GTIDs may be lost causing replication to fail. Always ensure binary logging remains enabled in replicated topologies.
Container Environments:
Docker and Kubernetes volumes often mount with root ownership. MySQL runs as the 'mysql' user and cannot write to root-owned directories. Solution: either change volume permissions or use named volumes that Docker manages.
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