The mysqld process failed to start because it couldn’t initialize its binary log files for transaction-level replication.
This means the database server is unable to record changes in a way that other replicas can understand, effectively halting any replication setup or preventing an existing one from catching up.
The most common culprit is insufficient disk space. Binary logs grow over time, and if the filesystem where they reside is full, mysqld can’t create new ones or write to existing ones.
Diagnosis: Check disk usage on the server hosting the MySQL data directory.
df -h /var/lib/mysql/
Fix:
Free up disk space by deleting old logs, temporary files, or unused data. For example, if /var/lib/mysql/ is on /dev/sda1 and it’s 100% full, you might delete old binary logs older than 7 days:
find /var/lib/mysql/ -name 'mysql-bin.*' -mtime +7 -delete
This works because binary logs are typically rotated and older ones can be safely removed once they’ve been replicated or purged.
A permissions issue on the binary log directory or files can also prevent mysqld from accessing them. The MySQL server process needs to own and have write permissions.
Diagnosis: Verify ownership and permissions of the MySQL data directory and any binary log files.
ls -ld /var/lib/mysql/
ls -l /var/lib/mysql/mysql-bin.*
Fix:
Ensure the mysql user owns the directory and files, and has read/write permissions.
sudo chown -R mysql:mysql /var/lib/mysql/
sudo chmod -R u+rwX /var/lib/mysql/
This grants the mysql user full control, allowing it to create, write, and manage the binary log files.
Corrupted or incomplete binary log files can cause initialization failures. This can happen due to unclean shutdowns or disk errors.
Diagnosis: Examine the MySQL error log for specific messages related to binary log corruption.
tail -n 100 /var/log/mysql/error.log
Look for messages like "Error writing to binary log" or "Could not find first log file name in binary log index". Fix: If corruption is suspected, you might need to reset the binary logs. Warning: This will cause replicas to lose sync and require re-initialization. First, stop MySQL:
sudo systemctl stop mysql
Then, rename or delete the existing binary log index file and the binary log files.
mv /var/lib/mysql/mysql-bin.index /var/lib/mysql/mysql-bin.index.bak
rm /var/lib/mysql/mysql-bin.*
Start MySQL. It will create a new mysql-bin.index and start with mysql-bin.000001.
sudo systemctl start mysql
This effectively tells MySQL to start logging from scratch, bypassing any problematic older logs.
An incorrect log_bin setting in my.cnf can point to a non-existent or inaccessible location.
Diagnosis:
Check the my.cnf (or my.ini) file for the log_bin directive.
grep log_bin /etc/mysql/my.cnf
Fix:
Ensure log_bin is set to a valid path where MySQL has write permissions. If you intend to use binary logging, uncomment or set it, e.g.:
[mysqld]
log_bin = /var/log/mysql/mysql-bin.log
server-id = 1
Then restart MySQL. This ensures the server knows where to write the binary logs and that the directory exists and is writable.
The binlog_format setting might be incompatible with the replication setup or a specific transaction. While less common for initial startup failures, it can contribute to issues.
Diagnosis:
Check the binlog_format in my.cnf or via SHOW VARIABLES.
mysql -e "SHOW VARIABLES LIKE 'binlog_format';"
Fix:
Ensure binlog_format is set to ROW, STATEMENT, or MIXED. ROW is generally recommended for consistency.
[mysqld]
binlog_format = ROW
Restart MySQL. This ensures the chosen format is applied correctly for logging transactions.
If the server-id is not set or is duplicated on replicas, replication features, including binary logging initialization, can fail.
Diagnosis:
Check my.cnf for server-id.
grep server-id /etc/mysql/my.cnf
Fix:
Ensure server-id is set and unique for each server in a replication topology.
[mysqld]
server-id = 1
Restart MySQL. A unique server-id is fundamental for replication and often a prerequisite for binary logging to function correctly in a replicated environment.
The next error you’ll likely encounter is a Slave I/O or Slave SQL thread failure on replicas, as they won’t be able to connect to or read from the primary.