What to Note When TDSQL Boundless is Used
What Monitoring Metrics Should Users Regularly Pay Attention to for Instances?
Warning:
To ensure the stable operation of database instances, TDSQL Boundless provides a storage space protection mechanism. When the storage utilization of a node reaches a specified threshold, the system automatically enables read-only protection to prevent instance exceptions caused by storage exhaustion. To avoid instance read-only lock due to not monitoring disk (storage space) changes in a timely manner, set up a disk utilization metric alarm. For the operation, see Setting Alarm Policy. Triggering the Read-Only Protection Mechanism: When the storage utilization of any node exceeds the system-defined threshold (default value: 91%), that node is automatically placed into read-only mode.
Impact of Read-Only Protection Mode: Write operations (such as INSERT, UPDATE, and DELETE) are rejected, but data query and cleanup operations (such as DROP and TRUNCATE) are unaffected. Data read/write operations on other nodes that have not triggered the threshold are also unaffected. Note: In a 3-replica scenario, if two or more replicas enter read-only mode, the entire instance will enter read-only mode. If you cannot quickly delete data via DROP or TRUNCATE, you can try scaling out the disk to bring the utilization below the threshold and then perform DELETE operations. You can also contact Tencent Cloud Technical Support to assist in evaluating and temporarily modifying the threshold to clean up data. Automatic Recovery from Read-Only Mode: When you reduce storage utilization below the system-defined threshold by scaling out or cleaning up data, the node automatically returns to read-write mode.
About DELETE: In the LSM Tree engine, a DELETE operation is appended as a "delete marker" and is therefore considered a write operation. It does not immediately reduce data volume. When the instance enters read-only mode, users cannot perform DELETE operations. DROP and TRUNCATE operations are unaffected.
CPU utilization, memory utilization, and disk space utilization. You can set alarm policies based on your actual situation. When you receive an alarm, you can take appropriate measures to clear it. What Content Occupies Disk Space on Instance Nodes?
Warning:
To prevent your database from being locked, be sure to monitor disk space alarms!
The storage space protection mechanism of TDSQL Boundless automatically enters read-only mode when the disk usage of a node exceeds the system-defined threshold (default value: 91%). At this point, your business write operations (INSERT/UPDATE/DELETE) will directly report errors until the usage drops below the threshold and normal operations resume. Be sure to set up a disk utilization alarm (recommended threshold: 75% to 80%) to allow yourself sufficient time to respond.
The used disk space of a node consists of data file space, log file space, and other space:
Data Files: Data files that users normally write (excluding backup data). The corresponding node monitoring metric is data file space usage.
Log Files: WAL log files (also known as Redo log files) required for the normal operation of a database instance. The corresponding node monitoring metric is log file usage.
Other: Binary executable files of the database engine, and so on
What Table Types Does TDSQL Boundless Support? Does It Support Single Tables, Broadcast Tables, and Partition Tables?
In TDSQL Boundless, regular tables are currently the primary supported type, including both partitioned and non-partitioned variants.
For partitioned tables, the data in different partitions can be distributed across different nodes.
For non-partitioned tables, if the data volume is large, the RG will be split and evenly distributed to each node.
TDSQL Boundless also supports broadcast tables: you can define a table to be replicated across all nodes when creating it.
Does TDSQL Boundless Provide Read/Write Splitting Capability?
Read-write separation is often used to solve the following two problems:
1. In a traditional leader/follower architecture, read-write separation can fully leverage the resources of the standby database.
2. For applications with distinct analytical processing (AP) and transaction processing (TP) business scenarios, read-write separation can avoid mutual interference between them.
However, the architecture of TDSQL Boundless differs from traditional leader/follower architectures (such as InnoDB). In TDSQL Boundless, data is evenly distributed across all nodes. Consequently, the CPU, I/O, and other resources of each node can be fully utilized, eliminating the need to rely on read-write separation to leverage standby database resources.
For scenarios that require isolating AP reading SQL from TP scenarios, we will provide corresponding support in later versions.
What Is the Current Disaster Recovery Capability Support Status of TDSQL Boundless?
TDSQL Boundless provides diversified service high-availability technologies, including multi-replica disaster recovery within an instance and physical standby database disaster recovery between instances.
Disaster recovery via multiple replicas within instances.
Three replicas in the same IDC: Three replicas in the same IDC form an instance, which can prevent minority node failures but cannot prevent IDC-level failures.
Intra-city three-replica and three-IDC: For scenarios with three IDCs for one city. Three IDCs in the same city form an instance (each IDC is an AZ), with network latency between IDCs generally ranging from 0.5ms to 2ms. This can prevent minority node failures and single IDC failures, but cannot prevent city-level failures.
Disaster recovery via physical standby databases between instances: It currently supports both intra-city and cross-city disaster recovery. It provides data sync and primary/secondary relationship switching capabilities between two completely independent instances. When the primary database becomes unavailable, either planned or unplanned, the standby database can take over the service.
Note:
1. Applications that handle key business have high requirements for business continuity. For this reason, they should be at the same disaster recovery level as the database. Otherwise, business will be affected in case of a failure even if the database can quickly recover.
2. If you choose disaster recovery via physical standby databases between instances, note that: Data synchronization between primary/standby instances is near real-time. Two switching modes are available: switchover (planned switch) and failover (switch when a failure is detected). Switchover can avoid losses, while failover causes losses (when failover is executed forcibly, it may typically incur under 5 seconds of data losses, depending on the actual lag of standby instance synchronization).
Why Does the Auto-Increment Field Exhibit Jumping Behavior in TDSQL Boundless?
In TDSQL Boundless databases, auto-increment fields are currently guaranteed to be globally unique but are not guaranteed to be globally auto-incrementing.
To improve the allocation efficiency of auto-increment field values, TDSQL Boundless adopts a shard caching mechanism. For example, if there are three compute nodes, they might each cache a range of consecutive auto-increment values:
Node A caches the auto-increment range 1-100.
Node B caches the auto-increment range 101-200.
Node C caches the auto-increment range 201-300.
When Node A's cached values are exhausted, it obtains the next available auto-increment range, for example, 301-400. This mechanism ensures that auto-increment field values can be allocated quickly even in A distributed environment, but it may also cause auto-increment values to jump because cached values across different nodes are not contiguous.
Does TDSQL Boundless Support JSON?
JSON is supported, and the JSON_ARRAYAGG and JSON_OBJECTAGG aggregate functions are also supported. (Currently, it is consistent with MySQL.)
Does TDSQL Boundless Support Foreign Keys and Global Indexes?
TDStore does not support foreign keys and global indexes. If you need to confirm whether migrating instances involves these features, contact technical support personnel to obtain a scan tool for judgment.
If a Transaction Is Eventually Rolled Back, What Will Happen to the Logs That Have Been Copied to Follower Nodes?
In the Raft protocol, if a transaction eventually needs to be rolled back, the log entries that have been copied to follower nodes will not be applied to the state machine, meaning that they will not affect the underlying data storage. This is because these log entries are deemed as "uncommitted".
The Raft protocol uses the following mechanism to ensure that uncommitted log entries are not incorrectly applied:
Maintain commitIndex: The Raft protocol uses a variable named commitIndex to track the maximum index of committed log entries. Only when a log entry's index is greater than commitIndex is it considered committed. If a transaction is rolled back, commitIndex remains unchanged, thus preventing uncommitted log entries from being applied to the state machine.
Log truncation: In some cases, for example, during a failover, a newly elected leader node may need to truncate its log to ensure cluster consistency. The new leader node deletes "uncommitted" entries in the log and synchronizes these changes to follower nodes. In this way, log entries related to rollback transactions are removed from the entire cluster.
Through these mechanisms, the Raft protocol ensures data consistency and integrity of the cluster even in the case of transaction rollback.
What Should I Do If the System Prompts "Instance Version Verification Error. Upgrade the Kernel to the Latest Version and Try Again"?
The TDSQL Boundless kernel is being continuously iterated and upgraded. If you encounter the system prompt mentioned above, contact Tencent Cloud Technical Support to upgrade the engine kernel for you.