Merge commit 'b570cc86270ba2e2b2b71d6eab8d717c2c8a1c56' into wenxuan/auto-embed

* commit 'b570cc86270ba2e2b2b71d6eab8d717c2c8a1c56': (48 commits)
  *: remove TiDB roadmap from TOC, home, index, add warning (#21628) (#21637)
  Update the scope of system-variable ”tidb_redact_log“ (#21513) (#21634)
  *: add custom Japanese localization for cloud docs (#21612)
  Modify the introduction of `cop_pool_size` (#21462) (#21627)
  tiflash: Update tiflash upgrade guide (#21619) (#21625)
  Update tidb-performance-tuning-config.md (#21621) (#21624)
  Update tidb-cloud-poc.md (#21336) (#21411)
  cloud: update the pricing link for starter  (#21620)
  ticdc: clarify descriptions of `index-value` and `columns` (#21616) (#21617)
  release-8.5: remove 'v' prefix from tidb-version variable (#21614)
  release-8.5: update version to 8.5.3 (#21613)
  cloud: fix note annotation syntax for proper rendering (#21611)
  ticdc: add key word for redo log (#21564) (#21607)
  ticdc: correct the tiup cluster command (#21135) (#21608)
  bump TiDB from v8.5.2 to v8.5.3 (#21578)
  v8.5.3: add release notes (#21399) (#21606)
  v8.5.3: log backup: update metafile format (#21412) (#21577)
  v8.5.3: update telemetry related doc files (#21404) (#21603)
  system-variables: add optimizer cost factors (#20748) (#21602)
  Add more description about SHARD_ROW_ID_BITS (#21467) (#21600)
  ...

Author: breezewish

TOC-tidb-cloud-essential.md

@@ -1,15 +1,13 @@
 <!-- markdownlint-disable MD007 -->
 <!-- markdownlint-disable MD041 -->
 
-- [Docs Home](https://docs.pingcap.com/)
 - About TiDB Self-Managed
   - [What is TiDB Self-Managed](/overview.md)
   - [TiDB 8.5 Release Notes](/releases/release-8.5.0.md)
   - [Features](/basic-features.md)
   - [MySQL Compatibility](/mysql-compatibility.md)
   - [TiDB Limitations](/tidb-limitations.md)
   - [Credits](/credits.md)
-  - [Roadmap](https://docs.pingcap.com/tidb/dev/tidb-roadmap)
 - Get Started
   - [Quick Start with TiDB](/quick-start-with-tidb.md)
   - [Quick Start with HTAP](/quick-start-with-htap.md)
@@ -1094,6 +1092,7 @@
   - [Release Support Policy](https://www.pingcap.com/tidb-release-support-policy/)
   - [TiDB Installation Packages](/binary-package.md)
   - v8.5
+    - [8.5.3](/releases/release-8.5.3.md)
     - [8.5.2](/releases/release-8.5.2.md)
     - [8.5.1](/releases/release-8.5.1.md)
     - [8.5.0](/releases/release-8.5.0.md)

TOC-tidb-cloud-starter.md

@@ -92,12 +92,6 @@ TiDB is highly compatible with the MySQL protocol and the common features and sy
 
 </DocHomeCard>
 
-<DocHomeCard href="/tidb/dev/tidb-roadmap" label="TiDB Self-Managed Roadmap" icon="oss-roadmap-blue">
-
-Planned features and release dates for TiDB Self-Managed.
-
-</DocHomeCard>
-
 </DocHomeCardContainer>
 
 The open-source TiDB platform is released under the Apache 2.0 license and is supported by the community. [View on GitHub](https://github.com/pingcap/tidb)

TOC-tidb-cloud.md

@@ -127,8 +127,6 @@ summary: TiDB is an open-source distributed SQL database that supports Hybrid Tr
 
 <LearningPath label="Reference" icon="cloud-dev">
 
-[TiDB Roadmap](https://docs.pingcap.com/tidb/dev/tidb-roadmap)
-
 [TiDB Configuration File Parameters](https://docs.pingcap.com/tidb/v8.5/tidb-configuration-file)
 
 [TiDB Command-line Flags](https://docs.pingcap.com/tidb/v8.5/command-line-flags-for-tidb-configuration)

TOC.md

@@ -209,7 +209,11 @@ After it is configured, you can check the monitoring to see a decreased number o
 
 #### Timeout-related parameters
 
-TiDB provides two MySQL-compatible parameters that controls the timeout: `wait_timeout` and `max_execution_time`. These two parameters respectively control the connection idle timeout with the Java application and the timeout of the SQL execution in the connection; that is to say, these parameters control the longest idle time and the longest busy time for the connection between TiDB and the Java application. The default value of both parameters is `0`, which by default allows the connection to be infinitely idle and infinitely busy (an infinite duration for one SQL statement to execute).
+TiDB provides the following MySQL-compatible timeout control parameters.
+
+- `wait_timeout`: controls the non-interactive idle timeout for the connection to Java applications. Starting from TiDB v5.4, the default value of `wait_timeout` is `28800` seconds, which is 8 hours. For TiDB versions earlier than v5.4, the default value is `0`, which means the timeout is unlimited.
+- `interactive_timeout`: controls the interactive idle timeout for the connection to Java applications. The value is 8 hours by default.
+- `max_execution_time`: controls the timeout for SQL execution in the connection, only effective for read-only SQL statements. The value is `0` by default, which allows the connection to be infinitely busy, that is, an SQL statement is executed for an infinitely long time.
 
 However, in an actual production environment, idle connections and SQL statements with excessively long execution time negatively affect databases and applications. To avoid idle connections and SQL statements that are executed for too long, you can configure these two parameters in your application's connection string. For example, set `sessionVariables=wait_timeout=3600` (1 hour) and `sessionVariables=max_execution_time=300000` (5 minutes).
 

_docHome.md

@@ -16,7 +16,7 @@ With PITR, you can satisfy the preceding requirements.
 
 ## Deploy the TiDB cluster and BR
 
-To use PITR, you need to deploy a TiDB cluster >= v6.2.0 and update BR to the same version as the TiDB cluster. This document uses {{{ .tidb-version }}} as an example.
+To use PITR, you need to deploy a TiDB cluster >= v6.2.0 and update BR to the same version as the TiDB cluster. This document uses v{{{ .tidb-version }}} as an example.
 
 The following table shows the recommended hardware resources for using PITR in a TiDB cluster.
 
@@ -43,13 +43,13 @@ Install or upgrade BR using TiUP:
 - Install:
 
     ```shell
-    tiup install br:{{{ .tidb-version }}}
+    tiup install br:v{{{ .tidb-version }}}
     ```
 
 - Upgrade:
 
     ```shell
-    tiup update br:{{{ .tidb-version }}}
+    tiup update br:v{{{ .tidb-version }}}
     ```
 
 ## Configure backup storage (Amazon S3)

_index.md

@@ -97,7 +97,7 @@ The complete PITR process is as follows:
 
 Log backup generates the following types of files:
 
-- `{resolved_ts}-{uuid}.meta` file: is generated every time each TiKV node uploads the log backup data and stores metadata of all log backup data files uploaded this time. The `{resolved_ts}` is the resolved timestamp of the TiKV node. The latest `resolved_ts` of the log backup task is the minimum resolved timestamp among all TiKV nodes. The `{uuid}` is generated randomly when the file is created.
+- `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta` file: is generated every time each TiKV node uploads the log backup data and stores metadata of all log backup data files uploaded this time. For the meaning of each field in the filename, see [Structure of backup files](#structure-of-backup-files).
 - `{store_id}.ts` file: is updated with global checkpoint ts every time each TiKV node uploads the log backup data. The `{store_id}` is the store ID of the TiKV node.
 - `{min_ts}-{uuid}.log` file: stores the KV change log data of the backup task. The `{min_ts}` is the minimum TSO timestamp of the KV change log data in the file, and the `{uuid}` is generated randomly when the file is created.
 - `v1_stream_truncate_safepoint.txt` file: stores the timestamp corresponding to the latest backup data in storage that deleted by `br log truncate`.
@@ -109,7 +109,7 @@ Log backup generates the following types of files:
 ├── v1
 │   ├── backupmeta
 │   │   ├── ...
-│   │   └── {resolved_ts}-{uuid}.meta
+│   │   └── {flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta
 │   ├── global_checkpoint
 │   │   └── {store_id}.ts
 │   └── {date}
@@ -122,7 +122,13 @@ Log backup generates the following types of files:
 
 Explanation of the backup file directory structure:
 
-- `backupmeta`: stores backup metadata. The `resolved_ts` in the filename indicates the backup progress, meaning that data before this TSO has been fully backed up. However, note that this TSO only reflects the progress of certain shards.
+- `backupmeta` directory: stores backup metadata files. Starting from v8.5.3, the naming convention of these files changes from `{resolved_ts}-{uuid}.meta` to `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`. The filename contains the following timestamp fields:
+    - `flushTs`: the timestamp when the backup file is periodically uploaded to the external storage. This value is obtained from PD and is globally unique.
+    - `minDefaultTs` (only applicable to Write CF files): the earliest transaction start time covered by this backup.
+    - `minTs` and `maxTs`: the minimum and maximum timestamps of all key-value data included in the backup file.
+
+    All these timestamps are encoded as fixed-length 16-digit hexadecimal strings, left-padded with zeros to ensure consistent length. This encoding design guarantees that filenames are naturally sorted in lexicographical order, making it efficient to perform batch listing and range filtering operations in external storage systems.
+
 - `global_checkpoint`: represents the global backup progress. It records the latest point in time to which data can be restored using `br restore point`.
 - `{date}/{hour}`: stores backup data for the corresponding date and hour. When cleaning up storage, always use `br log truncate` instead of manually deleting data. This is because the metadata references the data in this directory, and manual deletion might lead to restore failures or data inconsistencies after restore.
 
@@ -133,9 +139,9 @@ The following is an example:
 ├── v1
 │   ├── backupmeta
 │   │   ├── ...
-│   │   ├── 435213818858112001-e2569bda-a75a-4411-88de-f469b49d6256.meta
-│   │   ├── 435214043785779202-1780f291-3b8a-455e-a31d-8a1302c43ead.meta
-│   │   └── 435214443785779202-224f1408-fff5-445f-8e41-ca4fcfbd2a67.meta
+│   │   ├── 060c4bc7b0cdd582-06097a780d1ba138-060ab960016d2f00-060c0b9e47d4787b.meta
+│   │   ├── 06123bc6a0cdd591-060c3d24585be000-060c4453954a4000-060c4bc7b0cdcfa4.meta
+│   │   └── 063c2ac1c0cdd5c3-0609d2e6b3bcb064-060ab960016d2f84-060c0b9e47d47a77.meta
 │   ├── global_checkpoint
 │   │   ├── 1.ts
 │   │   ├── 2.ts