How to fix ERROR 1183: Got error during CHECKPOINT in MySQL

MySQLADVANCEDCRITICAL

MySQL ERROR 1183 occurs when InnoDB fails during a checkpoint operation, which flushes modified data from memory to disk. This critical error usually indicates disk I/O problems, insufficient disk space, file system issues, or hardware failures. Resolve it by checking disk health, freeing space, restarting MySQL, and investigating the error log for the underlying cause.

What this error means

MySQL ERROR 1183 (ER_ERROR_DURING_CHECKPOINT) is triggered when the InnoDB storage engine encounters a failure during a checkpoint operation. A checkpoint is an internal process where InnoDB flushes modified database pages from the buffer pool to disk, ensuring data durability and consistency. This is a critical operation that occurs periodically during normal database operation. When a checkpoint fails, it usually indicates one of these issues: the disk is full or nearly full, the file system has errors or became read-only, the disk is experiencing I/O errors due to hardware failure, or there are file permission problems preventing writes. The error message includes an additional error code (shown as "%d" in the generic message) that identifies the specific operating system error that caused the checkpoint to fail. Unlike some errors that recover automatically, checkpoint failures are serious because they prevent InnoDB from ensuring that recent changes are safely written to disk. If the server crashes after a failed checkpoint without successful recovery, data loss or corruption could occur.

How to fix "ERROR 1183: Got error during CHECKPOINT"

1Check available disk space immediately

The most common cause of checkpoint failures is insufficient disk space. Check all partitions, especially those containing MySQL data, logs, and temporary files.

bash

df -h

Look for partitions showing high usage (>90%) or full (100%). For example:

bash

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       100G   95G  5.0G  95% /
/dev/sda2        50G   48G  2.0G  96% /var/lib/mysql
tmpfs            16G   15G  1.0G  94% /tmp

Also check the MySQL data directory specifically:

bash

du -sh /var/lib/mysql
du -sh /var/log/mysql
du -sh /tmp

If any partition is >95% full, you must free space before MySQL can recover.

2Free up disk space by removing old logs and data

If disk is the issue, immediately free space by removing old binary logs, temporary files, and unnecessary data.

Stop MySQL first to prevent further operations:

bash

sudo systemctl stop mysql

Remove old binary logs (these are safe to delete if backed up):

bash

# Find and remove old binary logs (older than 30 days)
sudo find /var/log/mysql -name 'mysql-bin.*' -mtime +30 -delete

# Remove old error logs
sudo find /var/log -name 'error.log*' -mtime +30 -delete

# Clear /tmp directory
sudo rm -rf /tmp/*

Check disk space again:

bash

df -h

You should have at least 10% free space (ideally 20%) for MySQL to operate safely.

3Restart MySQL and monitor the error log

Once you have freed disk space, restart MySQL and watch the error log for signs of the checkpoint failure repeating.

bash

sudo systemctl start mysql

Monitor the error log in real-time:

bash

sudo tail -f /var/log/mysql/error.log

Look for lines like:

bash

[ERROR] [MY-012651] [InnoDB] Got error -1 during CHECKPOINT
[ERROR] [MY-012651] [InnoDB] Got error 28 during CHECKPOINT

The error code after "error" provides clues:
- Error 28 (ENOSPC): No space left on device
- Error 13 (EACCES): Permission denied
- Error 5 (EIO): Input/output error (hardware problem)
- Error 24 (EMFILE): Too many open files

If the error persists after freeing space, investigate the specific error code.

4Check file system health and permissions

If disk space is available but the error continues, check the file system for corruption and verify MySQL permissions.

Check file system for errors:

bash

# Check the file system (requires unmounting or running at boot)
sudo fsck -n /dev/sda2  # -n flag runs read-only check without repairs

# Or use e2fsck for ext4
sudo e2fsck -n /dev/sda2

If errors are found and you need to repair, you must stop MySQL and unmount the file system first (this requires downtime).

Check MySQL data directory permissions:

bash

ls -ld /var/lib/mysql
ls -l /var/lib/mysql/ib_logfile*
ls -l /var/lib/mysql/ibdata*

All files should be owned by the mysql user and group. Fix permissions if needed:

bash

sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysql
sudo chmod 660 /var/lib/mysql/ibdata*
sudo chmod 660 /var/lib/mysql/ib_logfile*

Restart MySQL:

bash

sudo systemctl restart mysql

5Check for disk I/O errors and hardware issues

If the error persists after freeing space and fixing permissions, investigate hardware-level disk failures.

Check the system log for I/O errors:

bash

sudo dmesg | grep -i error | tail -20
sudo journalctl -p err -n 50

Look for messages like:

bash

[Hardware Error]: Machine check from unknown source
I/O error dev sda, sector 12345
Buffer I/O error on device sda1

Run disk diagnostics:

bash

# Check disk SMART status (if supported)
sudo smartctl -a /dev/sda

# Run read/write tests (requires downtime)
sudo badblocks -v /dev/sda1

If SMART reports failing disks or many read errors, the disk is likely failing and needs replacement. This is a hardware issue, not a MySQL configuration problem.

For cloud environments, check the hypervisor logs and request disk replacement from your provider.

6Increase log file size and expand storage

If your database is legitimately large and growing, configure MySQL to use larger log files and expand storage capacity.

Increase InnoDB log file size in /etc/mysql/my.cnf:

ini

[mysqld]
# Increase log file size (default is usually 48MB)
# Value is per log file, and there are typically 2 log files
innodb_log_file_size = 1G

# Increase buffer pool if server has sufficient RAM
innodb_buffer_pool_size = 8G

Before changing log file size, you must stop MySQL and rename/remove the old log files:

bash

sudo systemctl stop mysql
cd /var/lib/mysql
sudo mv ib_logfile0 ib_logfile0.bak
sudo mv ib_logfile1 ib_logfile1.bak
sudo systemctl start mysql

For storage expansion in cloud environments:

bash

# AWS EBS example
sudo resize2fs /dev/xvda1

# Azure managed disk example
sudo parted /dev/sda
# Type: resizepart
# Number: 1
# End: 100%
sudo resize2fs /dev/sda1

For physical servers, add additional storage or migrate to a larger volume:

bash

sudo systemctl stop mysql
sudo mv /var/lib/mysql /mnt/large_disk/mysql
# Update /etc/mysql/my.cnf: datadir = /mnt/large_disk/mysql
sudo chown -R mysql:mysql /mnt/large_disk/mysql
sudo systemctl start mysql

7Monitor and set up alerts to prevent recurrence

Implement monitoring to prevent checkpoint failures from happening again.

Set up disk space monitoring:

bash

# Add to crontab to check every 2 hours
0 */2 * * * df -h | awk 'NR>1 {if ($5+0 > 80) print "Disk Alert: " $6 " is " $5 " full"}' | mail -s "MySQL Disk Alert" [email protected]

Monitor the MySQL error log for checkpoint errors:

bash

# Add to crontab to check every 4 hours
0 */4 * * * grep "CHECKPOINT" /var/log/mysql/error.log | tail -100 | mail -s "MySQL Checkpoint Report" [email protected]

Use cloud-native monitoring:

bash

# AWS CloudWatch, Azure Monitor, or similar services
# Set alerts for:
# - Disk usage > 80%
# - InnoDB pages not flushed
# - MySQL errors per minute > threshold

Keep at least 20% disk space free at all times. Configure log rotation and purge to prevent log files from consuming all space:

bash

# Configure logrotate for MySQL error logs
# Edit /etc/logrotate.d/mysql-server
/var/log/mysql/error.log {
    daily
    rotate 10
    compress
    delaycompress
    notifempty
    create 0660 mysql mysql
    sharedscripts
    postrotate
        systemctl reload mysql > /dev/null 2>&1 || true
    endscript
}

How to fix ERROR 1183: Got error during CHECKPOINT in MySQL

What this error means

Typical symptoms

Common causes

How to fix "ERROR 1183: Got error during CHECKPOINT"

Advanced notes

Related errors

Official resources & further reading