How to fix ERROR 1598: Binary logging not possible in MySQL

MySQLINTERMEDIATEHIGHUpdated Dec 25, 2025· 161 views

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.

Quick fix

Fixes 1598

SHOW GLOBAL VARIABLES LIKE 'binlog_format';
SHOW GLOBAL VARIABLES LIKE 'transaction_isolation';
  1. Check your current binary log format and isolation level
  2. Change binary log format to ROW (most compatible solution)
  3. Alternative: Use MIXED format for statement/row switching
  4. Fix transaction isolation level if needed
mysql — error
SHOW GLOBAL VARIABLES LIKE 'binlog_format';
SHOW GLOBAL VARIABLES LIKE 'transaction_isolation';
ERROR 1598: Binary logging not possible

What this error means

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.

Typical symptoms

  • Query execution fails with 'ERROR 1598' message
  • Replication stops or won't start
  • MySQL service fails to start or crashes during startup
  • Transactions are rejected after changing isolation levels
  • Binary log file cannot be created at startup
  • Permission denied errors in MySQL error log when writing binlog

Common causes

  1. READ-COMMITTED or READ-UNCOMMITTED isolation level used with STATEMENT-based binary logging on InnoDB tables
  2. MySQL daemon lacks write permissions to datadir or existing binary log files (common in Docker/container environments)
  3. Disk is full or insufficient free space for creating binary log files
  4. Incorrect --log-bin path in my.cnf after server upgrade or migration
  5. Volume permissions changed to root ownership (especially in containerized environments)
  6. SELinux or AppArmor policies blocking write access to binlog directory

How to fix "ERROR 1598: Binary logging not possible"

1Check your current binary log format and isolation level

Connect to MySQL and verify the current settings:

sql
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.

2Change binary log format to ROW (most compatible solution)

For persistent changes, edit your MySQL configuration file (/etc/mysql/my.cnf or /etc/my.cnf):

ini
[mysqld]
binlog_format = ROW

Then restart MySQL:

bash
sudo systemctl restart mysql
# or on systems using mysqld_safe:
sudo mysqld_safe

ROW-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):

sql
SET GLOBAL binlog_format = 'ROW';
3Alternative: Use MIXED format for statement/row switching

If you prefer automatic format switching, MIXED mode uses statement-based logging by default but switches to row-based for unsafe statements:

ini
[mysqld]
binlog_format = MIXED

Then restart MySQL. MIXED format provides a good balance but may cause larger binary logs than pure ROW format.

4Fix transaction isolation level if needed

If you're using a READ-COMMITTED or READ-UNCOMMITTED isolation level, consider changing to REPEATABLE-READ:

sql
SET GLOBAL transaction_isolation = 'REPEATABLE-READ';

This setting takes effect for new connections. Existing connections retain their previous isolation level.

5Check filesystem permissions (if error persists)

If you still see the error after configuration changes, verify the MySQL daemon can write to the datadir:

bash
# 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/mysql

In Docker/Kubernetes environments, ensure the volume is mounted with mysql (uid 999 or similar) ownership:

bash
docker run -d \
  -v /path/to/volume:/var/lib/mysql \
  mysql:latest
6Check disk space if binary log creation fails

If the binary log cannot be created at startup, verify free disk space:

bash
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 MySQL
7Validate configuration before restart

Always test your configuration file syntax before restarting:

bash
mysqld --validate-config

This catches syntax errors and prevents startup failures. Look for "mysqld: ready for connections" in the output.

Advanced notes

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.

Frequently asked questions

What does "1598" mean?
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.
How do I fix "1598"?
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.
What causes "1598"?
READ-COMMITTED or READ-UNCOMMITTED isolation level used with STATEMENT-based binary logging on InnoDB tables MySQL daemon lacks write permissions to datadir or existing binary log files (common in Docker/container environments) Disk is full or insufficient free space for creating binary log files
Is the "1598" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading