Configuring Local Binlog Retention Policy

Recent Pages

Configuring Local Binlog Retention Policy

Last updated: 2024-09-11 09:48:07

This document describes how to configure the local binlog retention period for a TencentDB for MySQL instance in the console.
 Note:
Single-node local disk instances (read-only instances) do not support configuring local binlog retention.
Cluster edition instances, dual-node instances, three-node instances, single-node cloud disk instances, and disaster recovery instances support configuring local binlog retention. The retention period policies are as follows.
The default local binlog retention period (in hours) for cluster edition instances, dual-node instances, and three-node instances is 120, with a range from 6 to 168.
The default local binlog retention period (in hours) for disaster recovery instances is 120, with a range from 120 to 168.
The default local binlog retention period (in hours) for single-node cloud disk instances is 120, with a range from 0 to 168.
If there is no disaster recovery instance for dual-node or three-node instances, the local binlog retention period (in hours) of the primary instance ranges from 6 to 168. If there is a disaster recovery instance or you plan to add one, to avoid synchronization exceptions, the local binlog retention period (in hours) of the primary instance should be no less than 120 hours, with a range from 120 to 168.
Binlog Description
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.
﻿
Overview
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%.
MySQL's data sync is based on binlog. To ensure database restorability, stability, and high availability, binlog cannot be disabled in TencentDB for MySQL.
The generated binlog files are automatically backed up to COS through the automatic backup feature provided by TencentDB for MySQL. The binlog files whose backups are already uploaded to COS will be cleared according the local binlog retention policy. To prevent exceptions, the binlog files in use cannot be cleared even they expire. Therefore, the local binlog clearing has a delay.
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.
Directions
1. Log in to the TencentDB for MySQL console and click an instance ID in the instance list to enter the instance management page.
2. On the instance management page, select the Backup and Restoration and click Configure Local Binlog.
3. In the pop-up dialog box, enter the desired retention period and space utilization, confirm the settings, and click  OK . You can refer to the corresponding instance operations below for settings.
Operations for Dual-Node and Three-Node Instances
Single-Node Cloud Disk Instance Operations
Disaster Recovery Instance Operations
Cluster Edition Instance Operations
﻿
Retention Period (hours): The maximum retention time for local binlog files after log backup is enabled. The default value is 120. You can set it to an integer in the range from 6 to 168.
Note:
If the local binlog retention period configured for dual-node or three-node instances is less than 120 hours, disaster recovery instances cannot be purchased for the primary instance. To mount a disaster recovery instance, the local binlog retention period of the primary instance should be no less than 120 hours.
Space Utilization Threshold (%): The default value is 30. You can set it to an integer in the range from 30 to 50.
Local binlog space utilization = Local binlog size/Total purchased instance space. The binlog space is recyclable. If the binlog space is used up, some of the earliest binlogs will be cleared until the binlog space utilization is lower than the threshold and all remaining binlogs are unexpired.
﻿
Retention Period (hours): The maximum retention time for local binlog files after log backup is enabled. The default value is 120. You can set it to an integer in the range from 0 to 168.
Space Utilization Threshold (%): The default value is 30. You can set it to an integer in the range from 30 to 50.
Local binlog space utilization = Local binlog size/Total purchased instance space. The binlog space is recyclable. If the binlog space is used up, some of the earliest binlogs will be cleared until the binlog space utilization is lower than the threshold and all remaining binlogs are unexpired.
﻿
Retention Period (hours): The maximum retention time for local binlog files after log backup is enabled. The default value is 120. You can set it to an integer in the range from 120 to 168.
Space Utilization Threshold (%): The default value is 30. You can set it to an integer in the range from 30 to 50.
Local binlog space utilization = Local binlog size/Total purchased instance space. The binlog space is recyclable. If the binlog space is used up, some of the earliest binlogs will be cleared until the binlog space utilization is lower than the threshold and all remaining binlogs are unexpired.
﻿
Retention Period (hours): The maximum retention time for local binlog files after log backup is enabled. The default value is 120. You can set it to an integer in the range from 6 to 168.
Space Utilization Threshold (%): The default value is 30. You can set it to an integer in the range from 30 to 50.
Local binlog space utilization = Local binlog size/Total purchased instance space. The binlog space is recyclable. If the binlog space is used up, some of the earliest binlogs will be cleared until the binlog space utilization is lower than the threshold and all remaining binlogs are unexpired.
FAQs
Will database restoration be affected if the local binlog retention period is too short?
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.
What is the default retention policy for local binlog?
The default local binlog retention period is 120 hours, and the space utilization will not exceed 30%. You can set the local binlog retention period according to your needs.
Will binlog files take up the instance disk space?
Yes. Before the binlog files are uploaded to COS and cleared according to the retention policy, they will be stored on the instance disk.
Why can I only set the minimum local binlog retention period to 120 hours?
Check whether your instance is a dual-node or three-node instance with a disaster recovery instance mounted. If a disaster recovery instance is mounted, to avoid synchronization exceptions, the minimum local binlog retention period of the primary instance can only be set to 120 hours.
Check whether the instance for which you are trying to modify the local binlog retention period is a disaster recovery instance. If it is a disaster recovery instance, to ensure proper synchronization, you need to set the retention period within the range from 120 to 168 hours.
Why can't I purchase a disaster recovery instance for my primary instance?
To create a disaster recovery instance for the primary instance, the following conditions should be met. Check accordingly.
The primary instance should be a dual-node or three-node instance.
The local binlog retention period of the primary instance should be greater than or equal to 120 hours.
The primary instance should have at least 1 GB memory and 50 GB hard disk space, and the version should be MySQL 5.6 or later (for MySQL 5.6, submit a ticket to apply for this feature), with the engine being InnoDB.