RDS for MySQL binary log rotates every approximately 5 minutes

The frequent binary log rotation you're observing every 5 minutes is related to RDS-managed operations, though the specific internal mechanism isn't explicitly documented in the available AWS documentation.

Regarding your questions:

1. Expected RDS behavior: Yes, this appears to be part of RDS's internal management operations. RDS performs various automated tasks including backup operations, monitoring, and log management that can trigger binary log rotations independent of the max_binlog_size setting.

2. Rotation mechanism: While the exact internal trigger isn't detailed in public documentation, RDS performs regular automated operations that can cause binary log rotation. The rotation occurs through internal RDS management processes rather than reaching the max_binlog_size threshold.

3. Operation type: The specific command (FLUSH LOGS vs internal operation) used by RDS isn't documented, but it's part of RDS's automated database management.

4. Controlling rotation interval: There is no customer-configurable parameter to control this automatic rotation interval. RDS manages binary log rotation as part of its service operations. However, you can control binary log retention using the mysql.rds_set_configuration stored procedure with the 'binlog retention hours' parameter (which you've already set to 72 hours).

5. Impact on replication and PITR: This rotation behavior should not negatively impact replication or point-in-time recovery. RDS is designed to maintain continuous binary logs for replication and PITR purposes. As long as your binlog retention period is sufficient (your 72-hour setting), the logs needed for replication and recovery will be available.

6. Official documentation: The available documentation discusses binary log retention configuration and the purging behavior, but doesn't specifically document the 5-minute rotation interval you're observing. This appears to be an internal RDS operational characteristic.

The key takeaway is that as long as your binlog retention hours are set appropriately for your replication and recovery needs, these frequent rotations are part of normal RDS operations and shouldn't cause issues with your database functionality.
Sources
Setting and showing binary log configuration - Amazon Relational Database Service
Accessing MySQL binary logs - Amazon Aurora

1 & 2. Expected behavior / Nature of the trigger

It is highly likely that RDS automatic backups (binary log transfer for PITR) are the cause.

In RDS, when backups are enabled, binary logs are backed up to S3 approximately every 5 minutes by default. This "5-minute" interval aligns with the fact that the RPO for RDS PITR is approximately 5 minutes.

Uploading to S3 requires a closed binary log file. Since the current file being written to cannot be transferred, the most logical explanation is that the RDS management agent periodically rotates the logs and transfers the finalized files.

This is also consistent with the facts you observed:

• Constant interval of approx. 5 minutes → Time-driven, not size-driven
• Size range of 642 bytes to ~9 KB → Rotates even with minimal write activity = Caused by an internal process
• Uptime does not reset → Not a restart
• Not immediately after rds_heartbeat2 → Separate from the heartbeat mechanism
• Increase in Com_flush → Some form of FLUSH operation is being executed

3. FLUSH LOGS or FLUSH BINARY LOGS?

It is impossible to say for certain. As you correctly noted, Com_flush is a general counter for FLUSH operations and does not distinguish between subtypes.

However, the following point serves as a useful clue for troubleshooting: If the error log and slow query log are also rotating at the same 5-minute interval, it is likely FLUSH LOGS; if only the binary log is rotating, it is likely FLUSH BINARY LOGS (or an equivalent internal API).

For reference, it is officially documented that RDS for MySQL writes mysql-error.log to disk and appends to mysql-error-running.log every 5 minutes. The existence of this same 5-minute cycle for the error log is significant, as it supports the possibility that the same management process handles both. Note that internal RDS management operations are not recorded in mysql.rds_history (which logs operations resulting from stored procedures executed by the customer); therefore, the absence of traces in the history is consistent with expected behavior.

4. Methods for modification or disabling

There appear to be no supported configuration parameters for this.

Theoretically, setting the backup retention period to 0 disables binary logging itself. Official documentation explicitly states that setting the retention period to 0 disables binary logs, but this also disables daily automated backups and the log_bin session variable. However, the documentation recommends against disabling backups; furthermore, since this naturally renders Point-in-Time Recovery (PITR) and read replicas unusable, it is not a practical option.

No parameters were found in publicly available information that allow for changing only the 5-minute interval.

5. Impact on replication and PITR

There should be no adverse effects on either.

• Replication: There is no functional impact, as replicas correctly process "Rotate" events and follow the stream to the next file.
• PITR: In fact, this behavior is the very mechanism that enables PITR. Stopping rotation would prevent the creation of units for transfer to S3, resulting in coarser granularity for recovery points.

A secondary effect is an increase in the number of files (approximately 288 per day) and, consequently, the number of directory entries; however, with a 72-hour retention period, the total is around 900 files—a volume that does not pose operational issues.

6. Official documentation No official documentation was found that explicitly explains this specific behavior.