tencent cloud

TencentDB for MySQL

Release Notes and Announcements
Release Notes
Product Announcements
User Tutorial
Product Introduction
Overview
Strengths
Use Cases
Database Architecture
Resource Isolation Policy
Economical Instance
Feature List
Database Instance
High Availability (Multi-AZ)
Regions and AZs
Service Regions and Service Providers
Kernel Features
Overview
Kernel Version Release Notes
Functionality Features
Performance Features
Security Features
Stability Features
TXRocks Engine
LibraDB Engine
Checking and Fixing Kernel Issues
Purchase Guide
Billing Overview
Selection Guide
Purchase Methods
Renewal
Payment Overdue
Refund
Pay-as-You-Go to Monthly Subscription
Instance Adjustment Fee
Backup Space Billing
Database Audit Billing Overview
Commercial Billing and Activity Description for Database Proxy
Description of the Database Proxy Billing Cycle
Viewing Bills
Getting Started
Overview
Creating MySQL Instance
Connecting to MySQL Instance
SQL Insight (Database Audit)
Overview
Viewing Audit Instance List
Enabling Audit Service
Viewing Audit Log
Log Shipping
Configuring Post-Event Alarms
Modifying Audit Rule
Modifying Audit Services
Disabling Audit Service
Audit Rule Template
SQL Audit Rule (Legacy)
Viewing Audit Task
Authorizing Sub-User to Use Database Audit
MySQL Cluster Edition
Introduction to TencentDB for MySQL Cluster Edition
Creating TencentDB for MySQL Cluster Edition Instance
Maintenance Management Instance
Viewing Instance Monitoring
Adjusting Instance Configuration
Operations for Other Features
Migrate or upgrade to TencentDB for MySQL Cluster Edition
Operation Guide
Use Limits
Operation Overview
Instance Management and Maintenance
Instance Upgrade
CPU Elastic Expansion
Read-Only/Disaster Recovery Instances
Database Proxy
Database Management Center (DMC)
Account Management
Parameter Configuration
Backup and Rollback
Data Migration
Network and Security
Monitoring and Alarms
Log Center
Read-Only Analysis Engine
Tag
Practical Tutorial
Using TencentDB for MySQL to Upgrade MySQL 5.7 to MySQL 8.0
Methods and Instructions for Upgrading from MySQL 5.6 to MySQL 5.7
Cybersecurity Classified Protection Practice for Database Audit of TencentDB for MySQL
Building All-Scenario High-Availability Architecture
Usage Specifications of TencentDB for MySQL
Configuring Automatic Application Reconnection
Impact of Modifying MySQL Source Instance Parameters
Limits on Automatic Conversion from MyISAM to InnoDB
Creating VPCs for TencentDB for MySQL
Enhancing Business Load Capacity with TencentDB for MySQL
Setting up 2-Region-3-DC Disaster Recovery Architecture
Improving TencentDB for MySQL Performance with Read/Write Separation
Migrating Data from InnoDB to RocksDB with DTS
Building LAMP Stack for Web Application
Building Drupal Website
Calling MySQL APIs in Python
The primary and secondary instances have inconsistent query data
White Paper
Performance White Paper
Security White Paper
Troubleshooting
Connections
Performance
Instance Data Sync Delay
Failure to Enable Case Insensitivity
Failure to Obtain slow_query_log_file via a Command
API Documentation
History
Introduction
API Category
Instance APIs
Making API Requests
Data Import APIs
Database Proxy APIs
Database Audit APIs
Security APIs
Task APIs
Backup APIs
Account APIs
Rollback APIs
Parameter APIs
Database APIs
Monitoring APIs
Log-related API
Data Types
Error Codes
FAQs
Related to Selection
Billing
Backup
Rollback
Connection and Login
Parameter Modifications
Instance Upgrade
Account Permissions
Performance and Memory
Ops
Data Migration
Features
Console Operations
Logs
Event
Database audit
Instance Switch Impact
API 2.0 to 3.0 Switch Guide
Service Agreement
Service Level Agreement
Terms of Service
Reference
Standards and Certifications
Contact Us
Glossary

Configuring Local Binlog Retention Policy

PDF
Focus Mode
Font Size
Last updated: 2025-08-19 14:55:44
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.
MySQL 5.5 instances do not support configuring local binlog retention policy.

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.

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback