TiDB 8.1.0 Release Notes

Get future Long-Term Support (LTS) release notices via email:

​

​

Release date: May 24, 2024

TiDB version: 8.1.0

Quick access: Quick start | Production deployment

TiDB 8.1.0 is a Long-Term Support Release (LTS).

Compared with the previous LTS 7.5.0, 8.1.0 includes new features, improvements, and bug fixes released in 7.6.0-DMR and 8.0.0-DMR. When you upgrade from 7.5.x to 8.1.0, you can download the TiDB Release Notes PDF to view all release notes between the two LTS versions. The following table lists some highlights from 7.6.0 to 8.1.0:

CategoryFeature/EnhancementDescription
Scalability and PerformanceAcceleration of cluster snapshot restore speed (GA in v8.0.0)With this feature, BR can fully leverage the scale advantage of a cluster, enabling all TiKV nodes in the cluster to participate in the preparation step of data restores. This feature can significantly improve the restore speed of large datasets in large-scale clusters. Real-world tests show that this feature can saturate the download bandwidth, with the download speed improving by 8 to 10 times, and the end-to-end restore speed improving by approximately 1.5 to 3 times.
Achieve up to 10 times faster for creating tables in batch (experimental, introduced in v7.6.0)With the implementation of the new DDL architecture in v7.6.0, the performance of batch table creation has witnessed a remarkable improvement, up to 10 times faster. This substantial enhancement drastically reduces the time needed for creating numerous tables. This acceleration is particularly noteworthy in SaaS scenarios, where the prevalence of high volumes of tables, ranging from tens to hundreds of thousands, is a common challenge.
Use Active PD Followers to enhance PD’s Region information query service (experimental, introduced in v7.6.0)TiDB v7.6.0 introduces an experimental feature “Active PD Follower”, which allows PD followers to provide Region information query services. This feature improves the capability of the PD cluster to handle GetRegion and ScanRegions requests in clusters with a large number of TiDB nodes and Regions, thereby reducing the CPU pressure on PD leaders.
Bulk DML for much larger transactions (experimental, introduced in v8.0.0)Large batch DML jobs, such as extensive cleanup jobs, joins, or aggregations, can consume a significant amount of memory and have previously been limited at very large scales. Bulk DML (tidb_dml_type = “bulk”) is a new DML type for handling large batch DML tasks more efficiently while providing transaction guarantees and mitigating OOM issues. This feature differs from import, load, and restore operations when used for data loading.
Enhance the stability of caching the schema information when there is a massive number of tables (experimental, introduced in v8.0.0)SaaS companies using TiDB as the system of record for their multi-tenant applications often need to store a substantial number of tables. In previous versions, handling table counts in the order of a million or more was feasible, but it had the potential to degrade the overall user experience. TiDB v8.0.0 improves the situation with the following enhancements:
  • Introduce a new schema information caching system, which provides a cache strategy based on the Least Recently Used (LRU) algorithm for table metadata. It prioritizes storing the metadata of frequently accessed tables in the cache, thereby reducing memory usage in scenarios with a large number of tables.
  • Implement a priority queue for auto analyze, making the process less rigid and enhancing stability across a wider array of tables.
Reliability and availabilityGlobal Sort (GA in v8.0.0)The Global Sort feature aims to improve the stability and efficiency of IMPORT INTO and CREATE INDEX. By globally sorting the data to be processed, this feature improves the stability, controllability, and scalability of data writing to TiKV, consequently enhancing the user experience and service quality of data import and index creation. With global sorting enabled, each IMPORT INTO or CREATE INDEX statement now supports importing or adding indexes for up to 40 TiB of data.
Cross-database SQL binding (introduced in v7.6.0)When managing hundreds of databases with the same schema, it is often necessary to apply SQL bindings across these databases. For example, in SaaS or PaaS data platforms, each user typically operates separate databases with the same schema and runs similar SQL queries on them. In this case, it is impractical to bind SQL for each database one by one. TiDB v7.6.0 introduces cross-database SQL bindings that enable matching bindings across all schema-equivalent databases.
Support TiProxy (GA in v8.0.0)Full support for the TiProxy service, easily deployable via deployment tooling, to manage and maintain connections to TiDB so that they live through rolling restarts, upgrades, or scaling events.
Data Migration (DM) officially supports MySQL 8.0 (GA in v7.6.0)Previously, using DM to migrate data from MySQL 8.0 is an experimental feature and is not available for production environments. TiDB v7.6.0 enhances the stability and compatibility of this feature to help you smoothly and quickly migrate data from MySQL 8.0 to TiDB in production environments. In v7.6.0, this feature becomes generally available (GA).
TiDB resource control supports managing queries that consume more resources than expected (GA in v8.1.0)Through the rules of resource groups, TiDB can automatically identify queries that consume more resources than expected, and then limit or cancel these queries. Even if the queries are not identified by the rules, you can still manually add query characteristics and take corresponding measures to reduce the impact of the sudden query performance problem on the entire database.
DB Operations and ObservabilitySupport monitoring index usage statistics (introduced in v8.0.0)Proper index design is a crucial prerequisite to maintaining database performance. TiDB v8.0.0 introduces the INFORMATION_SCHEMA.TIDB_INDEX_USAGE table and the sys.schema_unused_indexes view to provide usage statistics of indexes. This feature helps you assess the efficiency of indexes in the database and optimize the index design.
Data MigrationTiCDC supports the Simple protocol (introduced in v8.0.0)TiCDC introduces a new protocol, the Simple protocol. This protocol provides in-band schema tracking capabilities by embedding table schema information in DDL and BOOTSTRAP events.
TiCDC supports the Debezium format protocol (introduced in v8.0.0)TiCDC introduces a new protocol, the Debezium protocol. TiCDC can now publish data change events to a Kafka sink using a protocol that generates Debezium style messages.
TiCDC supports client authentication (introduced in v8.1.0)TiCDC supports client authentication using mutual Transport Layer Security (mTLS) or TiDB username and password. This feature enables CLI or OpenAPI clients to authenticate their connections to TiCDC.

Feature details

Reliability

  • Support managing queries that consume more resources than expected (GA) #43691 @nolouch

    Sudden SQL query performance problems can cause a decline in overall database performance, which is the most common challenge to database stability. The reasons for these problems are diverse, such as untested new SQL statements, drastic changes in data volume, and sudden changes in execution plans. These problems are difficult to avoid completely at the source. TiDB v7.2.0 has introduced the capability to manage queries that consume more resources than expected to quickly reduce the impact of sudden query performance problems. This feature becomes generally available in v8.1.0.

    You can set the maximum execution time for a query in a resource group. When the execution time of a query exceeds the set value, the priority of the query is automatically reduced or the query is canceled. You can also set immediately matching identified queries through text or execution plans within a period of time, to avoid excessive resource consumption during the identification phase when the concurrency of problematic queries is too high.

    TiDB also supports the manual marking of queries. By using the QUERY WATCH command, you can mark queries based on the SQL text, SQL Digest, or execution plan. The queries that match the mark can be downgraded or canceled, achieving the purpose of adding a SQL blocklist.

    The automatic management capability of queries that consume more resources than expected provides users with an effective means to quickly mitigate the impact of query problems on overall performance before the root cause is identified, thereby improving the stability of the database.

    For more information, see documentation.

SQL

  • Support using more expressions to set default column values when creating a table (GA) #50936 @zimulala

    Before v8.0.0, when you create a table, the default value of a column is limited to strings, numbers, dates, and certain expressions. Starting from v8.0.0, you can use more expressions as the default column values. For example, you can set the default value of a column to DATE_FORMAT. This feature helps you meet more diverse requirements. In v8.1.0, this feature becomes GA.

    Starting from v8.1.0, you can use expressions as default values when adding columns by ADD COLUMN.

    For more information, see documentation.

DB operations

  • Enable the TiDB Distributed eXecution Framework (DXF) by default to enhance the performance and stability of ADD INDEX or IMPORT INTO tasks in parallel execution #52441 @D3Hunter

    The DXF becomes generally available (GA) in v7.5.0, but it is disabled by default. This means that an ADD INDEX or IMPORT INTO task is executed only by one TiDB node by default.

    Starting from v8.1.0, TiDB enables this feature by default (tidb_enable_dist_task defaults to ON). When enabled, the DXF can schedule multiple TiDB nodes to execute the same ADD INDEX or IMPORT INTO task in parallel, fully utilizing the resources of the TiDB cluster and greatly improving the performance of these tasks. In addition, you can linearly improve the performance of ADD INDEX and IMPORT INTO tasks by adding TiDB nodes and configuring tidb_service_scope for the newly added nodes.

    For more information, see documentation.

Security

  • Enhance TiDB log desensitization (GA) #52364 @xhebox

    The enhanced TiDB log desensitization supports removing sensitive data when users view logs, implemented by marking SQL text information in log files. You can control whether to mark log information to enable secure use of TiDB logs in different scenarios, enhancing the security and flexibility of using log desensitization. To use this feature, set the system variable tidb_redact_log to MARKER, and then the SQL text in TiDB’s runtime logs is marked. In addition, you can use the collect-log subcommand on the TiDB server to remove marked sensitive data from the logs and display the logs in a secure manner. You can also remove all markers and get the normal logs. This feature became generally available in v8.1.0.

    For more information, see documentation.

Data migration

  • Support the IMPORT INTO ... FROM SELECT syntax (GA) #49883 @D3Hunter

    Before v8.0.0, importing query results into a target table could only be done using the INSERT INTO ... SELECT statement, which is relatively inefficient in some large dataset scenarios. In v8.0.0, TiDB introduces IMPORT INTO ... FROM SELECT as an experimental feature, which enables you to import the results of a SELECT query into an empty TiDB target table. It achieves up to 8 times the performance of INSERT INTO ... SELECT and significantly reduces the import time. In addition, you can use IMPORT INTO ... FROM SELECT to import historical data queried with AS OF TIMESTAMP.

    In v8.1.0, the IMPORT INTO ... FROM SELECT syntax becomes generally available (GA), enriching the functionality scenarios of the IMPORT INTO statement.

    For more information, see documentation.

  • TiDB Lightning simplifies conflict resolution strategies and supports handling conflicting data using the replace strategy (GA) #51036 @lyzx2001

    Before v8.0.0, TiDB Lightning has one data conflict resolution strategy for the logical import mode and two data conflict resolution strategies for the physical import mode, which are not easy to understand and configure.

    In v8.0.0, TiDB Lightning deprecates the old version of conflict detection strategy for the physical import mode, enables you to control the conflict detection strategy for both logical and physical import modes via the conflict.strategy parameter (experimental), and simplifies the configuration of this parameter. In addition, in the physical import mode, the replace strategy supports retaining the latest data and overwriting the old data when the import detects data with primary key or unique key conflicts. In v8.1.0, the capability to handle conflicting data with the replace strategy becomes generally available (GA).

    For more information, see documentation.

  • TiCDC supports client authentication #10636 @CharlesCheung96

    In v8.1.0, TiCDC supports client authentication when you are using the TiCDC CLI or OpenAPI. This feature enables you to configure TiCDC to require client authentication using client certificates, thereby establishing mutual Transport Layer Security (mTLS). Additionally, you can configure authentication based on TiDB username and password.

    For more information, see documentation.

Compatibility changes

8.1.0 - 图1

Note

This section provides compatibility changes you need to know when you upgrade from v8.0.0 to the current version (v8.1.0). If you are upgrading from v7.6.0 or earlier versions to the current version, you might also need to check the compatibility changes introduced in intermediate versions.

Behavior changes

  • In earlier versions, the tidb.tls configuration item in TiDB Lightning treats values "false" and "" the same, as well as treating the values "preferred" and "skip-verify" the same. Starting from v8.1.0, TiDB Lightning distinguishes the behavior of "false", "", "skip-verify", and "preferred" for tidb.tls. For more information, see TiDB Lightning configuration.
  • For tables with AUTO_ID_CACHE=1, TiDB supports a centralized auto-increment ID allocating service. In earlier versions, the primary TiDB node of this service automatically performs a forceRebase operation when the TiDB process exits (for example, during the TiDB node restart) to keep auto-assigned IDs as consecutive as possible. However, when there are too many tables with AUTO_ID_CACHE=1, executing forceRebase becomes very time-consuming, preventing TiDB from restarting promptly and even blocking data writes, thus affecting system availability. To resolve this issue, starting from v8.1.0, TiDB removes the forceRebase behavior, but this change will cause some auto-assigned IDs to be non-consecutive during the failover.
  • In earlier versions, when processing a transaction containing UPDATE changes, if the primary key or non-null unique index value is modified in an UPDATE event, TiCDC splits this event into DELETE and INSERT events. Starting from v8.1.0, when using the MySQL sink, TiCDC only splits an UPDATE event into DELETE and INSERT events if the primary key or non-null unique index value is modified in the UPDATE event and the transaction commitTS is less than TiCDC thresholdTs (which is the current timestamp that TiCDC fetches from PD at TiCDC startup). This behavior change addresses the issue of downstream data inconsistencies caused by the potentially incorrect order of UPDATE events received by TiCDC, which can lead to an incorrect order of split DELETE and INSERT events. For more information, see documentation.

System variables

Variable nameChange typeDescription
tidbauto_analyze_ratioModifiedChanges the value range from [0, 18446744073709551615] to (0, 1].
tidb_enable_dist_taskModifiedChanges the default value from OFF to ON. This means that Distributed eXecution Framework (DXF) is enabled by default, which fully utilizes the resources of the TiDB cluster and greatly improves the performance of ADD INDEX and IMPORT INTO tasks. If you want to upgrade a cluster with the DXF enabled to v8.1.0 or later, disable the DXF (by setting tidb_enable_dist_task to OFF) before the upgrade, which avoids ADD INDEX operations during the upgrade causing data index inconsistency. After the upgrade, you can manually enable the DXF.
tidb_service_scopeModifiedChanges the optional value from “” or background to a string with a length of up to 64 characters, which enables you to control the service scope of each TiDB node more flexibly. Valid characters include digits 0-9, letters a-zA-Z, underscores , and hyphens -. The Distributed eXecution Framework (DXF) determines which TiDB nodes can be scheduled to execute distributed tasks based on the value of this variable. For specific rules, see Task scheduling.

Configuration file parameters

Configuration fileConfiguration parameterChange typeDescription
TiDBconcurrently-init-statsNewly addedControls whether to initialize statistics concurrently during TiDB startup. The default value is false.
TiDB Lightningconflict.max-record-rowsModifiedStarting from v8.1.0, there is no need to configure conflict.max-record-rows manually, because TiDB Lightning automatically assigns the value of conflict.max-record-rows with the value of conflict.threshold, regardless of the user input. conflict.max-record-rows will be deprecated in a future release.
TiDB Lightningconflict.thresholdModifiedChanges the default value from 9223372036854775807 to 10000 to quickly interrupt abnormal tasks so that you can make corresponding adjustments as soon as possible. This saves time and computational resources by avoiding the scenario where a large amount of conflicting data is discovered after the import, caused by abnormal data sources or incorrect table schema definitions.
TiCDCsecurity.client-allowed-userNewly addedLists the usernames that are allowed for client authentication. Authentication requests with usernames not in this list will be rejected. The default value is null.
TiCDCsecurity.client-user-requiredNewly addedControls whether to use username and password for client authentication. The default value is false.
TiCDCsecurity.mtlsNewly addedControls whether to enable the TLS client authentication. The default value is false.
TiCDCsink.debezium.output-old-valueNewly addedControls whether to output the value before the row data changes. The default value is true. When it is disabled, the UPDATE event does not output the “before” field.
TiCDCsink.open.output-old-valueNewly addedControls whether to output the value before the row data changes. The default value is true. When it is disabled, the UPDATE event does not output the “p” field.

Deprecated features

  • It is planned to redesign the auto-evolution of execution plan bindings in subsequent releases, and the related variables and behavior will change.
  • The TiDB Lightning parameter conflict.max-record-rows is scheduled for deprecation in a future release and will be subsequently removed. This parameter will be replaced by conflict.threshold, which means that the maximum number of conflicting records is consistent with the maximum number of conflicting records that can be tolerated in a single import task.
  • Starting from v8.0.0, TiDB Lightning deprecates the old version of conflict detection strategy for the physical import mode, and enables you to control the conflict detection strategy for both logical and physical import modes via the conflict.strategy parameter. The duplicate-resolution parameter for the old version of conflict detection will be removed in a future release.

Improvements

  • TiDB

    • Improve the MySQL compatibility of foreign keys displayed in the output of SHOW CREATE TABLE #51837 @negachov
    • Improve the MySQL compatibility of expression default values displayed in the output of SHOW CREATE TABLE #52939 @CbcWestwolf
    • Support adding multiple indexes concurrently in the ingest mode #52596 @lance6716
    • Support configuring the system variable tidb_service_scope with various values, enhancing the utilization of the Distributed eXecution Framework (DXF) #52441 @ywqzzy
    • Enhance the handling of DNF items that are always false by directly ignoring such filter conditions, thus avoiding unnecessary full table scans #40997 @hi-rustin
    • Support using Optimizer Fix Controls to remove the limitation that the optimizer does not automatically choose Index Merge for a query when the optimizer can choose the single index scan method (other than full table scan) for the query #52869 @time-and-fate
    • Add the total_kv_read_wall_time metric to the column execution info of Coprocessor operators #28937 @cfzjywxk
    • Add the RU (max) metric on the Resource Control dashboard #49318 @nolouch
    • Add a timeout mechanism for LDAP authentication to avoid the issue of resource lock (RLock) not being released in time #51883 @YangKeao

  • TiKV

  • PD

    • Optimize the logic for OperatorController to reduce the overhead of competition locks #7897 @nolouch

  • TiFlash

    • Mitigate the issue that TiFlash might panic due to updating certificates after TLS is enabled #8535 @windtalker

  • Tools

    • Backup & Restore (BR)

      • Add PITR integration test cases to cover compatibility testing for log backup and adding index acceleration #51987 @Leavrth
      • Remove the invalid verification for active DDL jobs when log backup starts #52733 @Leavrth
      • Add test cases to test compatibility between PITR and the acceleration of adding indexes feature #51988 @Leavrth
      • BR cleans up empty SST files during data recovery #16005 @Leavrth

    • TiCDC

      • Improve memory stability during data recovery using redo logs to reduce the probability of OOM #10900 @CharlesCheung96
      • Significantly improve the stability of data replication in transaction conflict scenarios, with up to 10 times performance improvement #10896 @CharlesCheung96

Bug fixes

  • TiDB

    • Fix the issue that executing SQL statements containing tables with multi-valued indexes might return the Can't find a proper physical plan for this query error #49438 @qw4990
    • Fix the issue that automatic statistics collection gets stuck after an OOM error occurs #51993 @hi-rustin
    • Fix the issue that after using BR to restore a table that has no statistics, the statistics health of that table is still 100% #29769 @winoros
    • Fix the issue that TiDB creates statistics for system tables during upgrade #52040 @hi-rustin
    • Fix the issue that automatic statistics collection is triggered before the initialization of statistics finishes #52346 @hi-rustin
    • Fix the issue that TiDB might crash when tidb_mem_quota_analyze is enabled and the memory used by updating statistics exceeds the limit #52601 @hawkingrei
    • Fix the issue that the TiDB synchronously loading statistics mechanism retries to load empty statistics indefinitely and prints the fail to get stats version for this histogram log #52657 @hawkingrei
    • Fix the issue that expressions containing different collations might cause the query to panic when the new framework for collations is disabled #52772 @wjhuang2016
    • Fix the issue that the CPS by type metric displays incorrect values #52605 @nolouch
    • Fix the issue that the nil pointer error occurs when you query INFORMATION_SCHEMA.TIKV_REGION_STATUS #52013 @JmPotato
    • Fix the incorrect error message displayed when an invalid default value is specified for a column #51592 @danqixu
    • Fix the issue that adding indexes in the ingest mode might cause inconsistent data index in some corner cases #51954 @lance6716
    • Fix the issue that DDL operations get stuck when restoring a table with the foreign key #51838 @YangKeao
    • Fix the issue that adding indexes fails when the TiDB network is isolated #51846 @ywqzzy
    • Fix the issue that adding an index with the same name after renaming an index causes an error #51431 @lance6716
    • Fix the issue of inconsistent data indexes caused by cluster upgrade during adding indexes #52411 @tangenta
    • Fix the issue that adding indexes to large tables fails after enabling the Distributed eXecution Framework (DXF) #52640 @tangenta
    • Fix the issue that adding indexes concurrently reports the error no such file or directory #52475 @tangenta
    • Fix the issue that the temporary data cannot be cleaned up after adding indexes fails #52639 @lance6716
    • Fix the issue that the metadata lock fails to prevent DDL operations from executing in the plan cache scenario #51407 @wjhuang2016
    • Fix the issue that the IMPORT INTO operation gets stuck when importing a large amount of data #52884 @lance6716
    • Fix the issue that TiDB unexpectedly restarts when logging gRPC errors #51301 @guo-shaoge
    • Fix the issue that IndexHashJoin outputs redundant data when calculating Anti Left Outer Semi Join #52923 @yibin87
    • Fix the incorrect result of the TopN operator in correlated subqueries #52777 @yibin87
    • Fix the inaccurate execution time statistics of HashJoin probe #52222 @windtalker
    • Fix the issue that using TABLESAMPLE returns incorrect results in static partition pruning mode (tidb_partition_prune_mode='static') #52282 @tangenta
    • Fix the issue that TTL is deviated by 1 hour in daylight saving time #51675 @lcwangchao
    • Fix the incorrect calculation and display of the number of connections (Connection Count) on the TiDB Dashboard Monitoring page #51889 @YangKeao
    • Fix the issue that the status gets stuck when rolling back the partition DDL tasks #51090 @jiyfhust
    • Fix the issue that the value of max_remote_stream is incorrect when executing EXPLAIN ANALYZE #52646 @JaySon-Huang
    • Fix the issue that querying the TIDB_HOT_REGIONS table might incorrectly return INFORMATION_SCHEMA tables #50810 @Defined2014
    • Fix the issue that the EXPLAIN statement might display incorrect column IDs in the result when statistics for certain columns are not fully loaded #52207 @time-and-fate
    • Fix the issue that the type returned by the IFNULL function is inconsistent with MySQL #51765 @YangKeao
    • Fix the issue that adding a unique index might cause TiDB to panic #52312 @wjhuang2016

  • TiKV

    • Fix the issue that resolve-ts is blocked when a stale Region peer ignores the GC message #16504 @crazycs520
    • Fix the issue that inactive Write Ahead Logs (WALs) in RocksDB might corrupt data #16705 @Connor1996

  • PD

    • Fix the issue that TSO might get stuck when toggling the PD microservice mode on and off #7849 @JmPotato
    • Fix the issue that the State monitoring metric for DR Auto-Sync does not show any data #7974 @lhy1024
    • Fix the issue that checking binary versions might cause PD panic #7978 @JmPotato
    • Fix the type conversion error that occurs when TTL parameters are parsed #7980 @HuSharp
    • Fix the issue that the Leader fails to transfer when you switch it between two deployed data centers #7992 @TonsnakeLin
    • Fix the issue that PrintErrln in pd-ctl fails to output error messages to stderr #8022 @HuSharp
    • Fix the issue that PD might panic when generating Merge schedules #8049 @nolouch
    • Fix the panic issue caused by GetAdditionalInfo #8079 @HuSharp
    • Fix the issue that the Filter target monitoring metric for PD does not provide scatter range information #8125 @HuSharp
    • Fix the issue that the query result of SHOW CONFIG includes the deprecated configuration item trace-region-flow #7917 @rleungx
    • Fix the issue that the scaling progress is not correctly displayed #7726 @CabinfeverB

  • TiFlash

    • Fix the issue that TiFlash might panic when you insert data to columns with invalid default values in non-strict sql_mode #8803 @Lloyd-Pottiger
    • Fix the issue that TiFlash might return transiently incorrect results in high-concurrency read scenarios #8845 @JinheLin
    • Fix the issue that in the disaggregated storage and compute architecture, the disk used_size metric displayed in Grafana is incorrect after you modify the value of the storage.remote.cache.capacity configuration item for TiFlash compute nodes #8920 @JinheLin
    • Fix the issue that TiFlash metadata might become corrupted and cause the process to panic when upgrading a cluster from a version earlier than v6.5.0 to v6.5.0 or later #9039 @JaySon-Huang
    • Fix the issue that in the disaggregated storage and compute architecture, TiFlash might panic when the compute node process is stopped #8860 @guo-shaoge
    • Fix the issue that TiFlash might return an error when executing queries containing virtual generated columns #8787 @guo-shaoge

  • Tools

    • Backup & Restore (BR)

      • Fix the issue that BR cannot back up the AUTO_RANDOM ID allocation progress in a union clustered index that contains an AUTO_RANDOM column #52255 @Leavrth
      • Fix the issue that removing a log backup task after it is paused does not immediately restore the GC safepoint #52082 @3pointer
      • Fix a rare issue that special event timing might cause the data loss in log backup #16739 @YuJuncen
      • Fix the issue that the global checkpoint of log backup is advanced ahead of the actual backup file write point due to TiKV restart, which might cause a small amount of backup data loss #16809 @YuJuncen
      • Fix the issue that the confusing information related to --concurrency appears in the log during a full backup #50837 @BornChanger
      • Fix the issue that the Region fetched from PD does not have a Leader when restoring data using BR or importing data using TiDB Lightning in physical import mode #51124 #50501 @Leavrth
      • Fix the issue that after pausing, stopping, and rebuilding the log backup task, the task status is normal, but the checkpoint does not advance #53047 @RidRisR
      • Fix the unstable test case TestClearCache #51671 @zxc111
      • Fix the unstable test case TestGetMergeRegionSizeAndCount #52095 @3pointer
      • Fix the unstable integration test br_tikv_outage #52673 @Leavrth
      • Fix the issue that the test case TestGetTSWithRetry takes too long to execute #52547 @Leavrth
      • Fix the issue that TiKV might panic when resuming a paused log backup task with unstable network connections to PD #17020 @YuJuncen

    • TiCDC

      • Fix the issue that calling the API (/api/v2/owner/resign) that evicts the TiCDC owner node causes the TiCDC task to restart unexpectedly #10781 @sdojjy
      • Fix the issue that when the downstream Pulsar is stopped, removing the changefeed causes the normal TiCDC process to get stuck, which causes other changefeed processes to get stuck #10629 @asddongmen
      • Fix the issue that the Ownership history panel in Grafana is unstable #10796 @hongyunyan
      • Fix the issue that restarting PD might cause the TiCDC node to restart with an error #10799 @3AceShowHand
      • Fix the issue that high latency in the PD disk I/O causes severe latency in data replication #9054 @asddongmen
      • Fix the issue that the default value of TIMEZONE type is not set according to the correct time zone #10931 @3AceShowHand
      • Fix the issue that DROP PRIMARY KEY and DROP UNIQUE KEY statements are not replicated correctly #10890 @asddongmen
      • Fix the issue that TiCDC fails to execute the Exchange Partition ... With Validation DDL downstream after it is written upstream, causing the changefeed to get stuck #10859 @hongyunyan

    • TiDB Lightning

      • Fix the issue that TiDB Lightning reports no database selected during data import due to incompatible SQL statements in the source files #51800 @lance6716
      • Fix the issue that TiDB Lightning might print sensitive information to logs in server mode #36374 @kennytm
      • Fix the issue that killing the PD Leader causes TiDB Lightning to report the invalid store ID 0 error during data import #50501 @Leavrth
      • Fix the issue that TiDB Lightning reports the Unknown column in where clause error when processing conflicting data using the replace strategy #52886 @lyzx2001
      • Fix the issue that TiDB Lightning panics when importing an empty table of Parquet format #52518 @kennytm

Performance test

To learn about the performance of TiDB v8.1.0, you can refer to the TPC-C performance test report and Sysbench performance test report of the TiDB Dedicated cluster.

Contributors

We would like to thank the following contributors from the TiDB community: