ApsaraDB RDS for MySQL always has binary logging enabled. Binary log files record all data changes and support primary/secondary replication. Understanding when these files are created and when they are purged helps you configure retention policies to balance storage cost and recoverability.
Binary log files stored locally on the instance are separate from log backup files uploaded to backup storage. Purging local binary log files does not affect your ability to restore data to a point in time within the backup retention period.
Binary log files vs. log backup files
| Binary log files | Log backup files | |
|---|---|---|
| Purpose | Enable primary/secondary replication and track all data changes. | Binary log files uploaded to backup storage in real time. Used to restore data to a specific point in time within the backup retention period. |
| Enable/disable | Always enabled; cannot be disabled. | Controlled by the log backup feature. |
| Storage location | Local instance storage. | OSS backup storage. |
Generation rules
RDS creates a new binary log file when any of the following conditions is met:
| Edition | New file trigger |
|---|---|
| RDS Basic Edition, RDS Cluster Edition, or RDS High-availability Edition | Current file exceeds 512 MB, or has been written to for more than 6 hours |
| RDS Enterprise Edition | Current file exceeds 512 MB |
A binary log file may be smaller than 512 MB if specific SQL commands are run or the instance restarts. A file may exceed 512 MB if a large transaction is in progress when the size limit is reached.
Clearing rules
Binary log files are purged automatically based on the Local Log Retention Policy settings in the ApsaraDB RDS console. The following parameters control when files are deleted.
| Parameter | Default | Description |
|---|---|---|
| Local Log Retention Duration | 3 hours | Maximum time to retain binary log files locally. Files older than this value are purged after they have been uploaded to backup storage. |
| Maximum Storage Space Usage | 30% | Maximum percentage of total instance storage that binary log files can occupy. When local binary log usage exceeds this threshold, the oldest files are purged. |
| Available Storage Space | — | Minimum available storage threshold. When available storage falls below this value, the oldest binary log files are purged immediately. |
When purging runs: The retention duration check runs when logs are flushed or rotated, not on a continuous schedule. If binary log files grow slowly and do not trigger rotation, files older than the retention duration may persist temporarily until the next rotation event.
Immediate purge on low storage: If instance storage usage exceeds 80% or available storage drops below 5 GB, and the Available Storage Space parameter is enabled, RDS purges binary log files immediately after they are generated.
Manual purge: To manually delete binary log files, go to Backup and Restoration in the console. Manual deletion is not supported for RDS Basic Edition instances. RDS retains the two most recent binary log files and uploads all others to an OSS bucket before deletion. The uploaded files are kept for the duration of your log backup retention period.
FAQ
Why are binary log files deleted immediately after generation?
This happens when instance storage usage exceeds 80% or available storage drops below 5 GB, and the Available Storage Space parameter in Local Log Retention Policy is enabled. Check available storage under Monitoring and Alerts and adjust the Available Storage Space threshold or increase instance storage.
Why are binary log files not being purged after the retention duration expires?
The retention duration is checked when a log rotation event occurs, not on a fixed schedule. If write activity is low and the current binary log file does not reach 512 MB or the 6-hour threshold, rotation does not trigger and older files may remain beyond the configured duration. Increasing write activity, restarting the instance, or flushing logs manually triggers rotation and starts the purge check.