This document describes how to set the binlog retention period for a TencentDB for MySQL instance in the console.
Note:
- You cannot configure local binlog retention for single-node instances of cloud disk edition.
- If there is a disaster recovery instance for the source instance, the local binlog retention period cannot be shorter than 120 hours.
Binlog grows fast when a TencentDB for MySQL instance executes large transactions or lots of DML operations. Binlog is split every 256 MB and uploaded to COS. You can see the uploaded binlog files in the log list in the console.
Before being uploaded to COS, binlog files are stored on the instance disk (i.e., locally). You can set the local binlog retention period, control the maximum percentage of disk space binlog can take up, or expand disk space in the console. We recommend that you clear data no longer used to keep the disk utilization below 80%.
Note:Rule for clearing expired binlog files:
The local binlog files are checked once every 60 seconds. If a binlog file's start time or space usage does not meet the set retention rule, it will be added to the queue of to-be-deleted files. The binlog files in the queue will be sorted by time and deleted starting from the oldest file one by one until the queue is cleared.
No, because the generated binlog files will be uploaded to COS through the automatic backup feature as soon as possible, and those not uploaded yet cannot be cleared. However, too short a retention period will affect the speed of rollback.
By default, the local binlog retention period is 120 hours, and the maximum binlog space utilization is 30%. You can customize the retention period as needed. If there is a disaster recovery instance for the source instance, it cannot be shorter than 120 hours; otherwise, it can range from 72 to 168 hours.
Yes. Before the binlog files are uploaded to COS and cleared according to the retention policy, they will be stored on the instance disk.
Was this page helpful?