Merge branch 'release-8.1' into add_concept_docs

TOC-tidb-cloud.md

@@ -23,7 +23,9 @@
   - [AI Features](/tidb-cloud/ai-feature-concepts.md)
   - [Data Service](/tidb-cloud/data-service-concepts.md) ![BETA](/media/tidb-cloud/blank_transparent_placeholder.png)
   - [Scalability](/tidb-cloud/scalability-concepts.md)
-  - [High Availability](/tidb-cloud/high-availability-with-multi-az.md)
+  - High Availability
+    - [Multi-AZ Deployments](/tidb-cloud/high-availability-with-multi-az.md)
+    - [High Availability in TiDB Cloud Serverless](/tidb-cloud/serverless-high-availability.md)
   - [Monitoring](/tidb-cloud/monitoring-concepts.md)
   - [Data Streaming](/tidb-cloud/data-streaming-concepts.md)
   - [Backup & Restore](/tidb-cloud/backup-and-restore-concepts.md)
@@ -313,6 +315,9 @@
   - [To Kafka Sink](/tidb-cloud/changefeed-sink-to-apache-kafka.md)
   - [To TiDB Cloud Sink](/tidb-cloud/changefeed-sink-to-tidb-cloud.md)
   - [To Cloud Storage](/tidb-cloud/changefeed-sink-to-cloud-storage.md)
+  - Reference
+    - [Set Up Self-Hosted Kafka Private Link Service in AWS](/tidb-cloud/setup-self-hosted-kafka-private-link-service.md)
+    - [Set Up Self-Hosted Kafka Private Service Connect in Google Cloud](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md)
 - Disaster Recovery
   - [Recovery Group Overview](/tidb-cloud/recovery-group-overview.md)
   - [Get Started](/tidb-cloud/recovery-group-get-started.md)
@@ -791,7 +796,8 @@
 ## RELEASES
 
 - Release Notes
-  - [2024](/tidb-cloud/tidb-cloud-release-notes.md)
+  - [2025](/tidb-cloud/tidb-cloud-release-notes.md)
+  - [2024](/tidb-cloud/release-notes-2024.md)
   - [2023](/tidb-cloud/release-notes-2023.md)
   - [2022](/tidb-cloud/release-notes-2022.md)
   - [2021](/tidb-cloud/release-notes-2021.md)

sql-statements/sql-statement-rename-table.md

@@ -5,7 +5,7 @@ summary: An overview of the usage of RENAME TABLE for the TiDB database.
 
 # RENAME TABLE
 
-This statement renames an existing table to a new name.
+This statement is used to rename existing tables and views, supporting renaming multiple tables at once and renaming across databases.
 
 ## Synopsis
 
@@ -20,21 +20,39 @@ TableToTable ::=
 ## Examples
 
 ```sql
-mysql> CREATE TABLE t1 (a int);
+CREATE TABLE t1 (a int);
+```
+
+```
 Query OK, 0 rows affected (0.12 sec)
+```
+
+```sql
+SHOW TABLES;
+```
 
-mysql> SHOW TABLES;
+```
 +----------------+
 | Tables_in_test |
 +----------------+
 | t1             |
 +----------------+
 1 row in set (0.00 sec)
+```
+
+```sql
+RENAME TABLE t1 TO t2;
+```
 
-mysql> RENAME TABLE t1 TO t2;
+```
 Query OK, 0 rows affected (0.08 sec)
+```
+
+```sql
+SHOW TABLES;
+```
 
-mysql> SHOW TABLES;
+```
 +----------------+
 | Tables_in_test |
 +----------------+
@@ -43,6 +61,103 @@ mysql> SHOW TABLES;
 1 row in set (0.00 sec)
 ```
 
+The following example demonstrates how to rename multiple tables across databases, assuming that the databases `db1`, `db2`, `db3`, and `db4` already exist, and that the tables `db1.t1` and `db3.t3` already exist:
+
+```sql
+RENAME TABLE db1.t1 To db2.t2, db3.t3 To db4.t4;
+```
+
+```
+Query OK, 0 rows affected (0.08 sec)
+```
+
+```sql
+USE db1; SHOW TABLES;
+```
+
+```
+Database changed
+Empty set (0.00 sec)
+```
+
+```sql
+USE db2; SHOW TABLES;
+```
+
+```
+Database changed
++---------------+
+| Tables_in_db2 |
++---------------+
+| t2            |
++---------------+
+1 row in set (0.00 sec)
+```
+
+```sql
+USE db3; SHOW TABLES;
+```
+
+```
+Database changed
+Empty set (0.00 sec)
+```
+
+```sql
+USE db4; SHOW TABLES;
+```
+
+```
+Database changed
++---------------+
+| Tables_in_db4 |
++---------------+
+| t4            |
++---------------+
+1 row in set (0.00 sec)
+```
+
+The atomic rename can be used to swap out a table without having any moment in which the table does not exist.
+
+```sql
+CREATE TABLE t1(id int PRIMARY KEY);
+```
+
+```
+Query OK, 0 rows affected (0.04 sec)
+```
+
+```sql
+CREATE TABLE t1_new(id int PRIMARY KEY, n CHAR(0));
+````
+
+```
+Query OK, 0 rows affected (0.04 sec)
+```
+
+```sql
+RENAME TABLE t1 TO t1_old, t1_new TO t1;
+```
+
+```
+Query OK, 0 rows affected (0.07 sec)
+```
+
+```sql
+SHOW CREATE TABLE t1\G
+```
+
+```
+*************************** 1. row ***************************
+       Table: t1
+Create Table: CREATE TABLE `t1` (
+  `id` int NOT NULL,
+  `n` char(0) DEFAULT NULL,
+  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
+1 row in set (0.00 sec)
+```
+
 ## MySQL compatibility
 
 The `RENAME TABLE` statement in TiDB is fully compatible with MySQL. If you find any compatibility differences, [report a bug](https://docs.pingcap.com/tidb/stable/support).

templates/copyright.tex

@@ -1,4 +1,4 @@
 
 \noindent \rule{\textwidth}{1pt}
 
-© 2024 PingCAP. All Rights Reserved.
+© 2025 PingCAP. All Rights Reserved.

tidb-binlog/tidb-binlog-configuration-file.md

@@ -305,6 +305,14 @@ If the safe mode is enabled, Drainer modifies the replication updates in the fol
 
 Default value: `false`
 
+#### load-schema-snapshot
+
+- Specifies how Drainer loads table information.
+- When you set it to `false`, Drainer replays all DDL operations from history to derive the table schema for each table at a specific schema version. This approach requires processing all DDL changes from the initial state to the target schema version, which might involve significant data processing and replaying.
+- When you set it to `true`, Drainer directly reads the table information at the checkpoint TS. Becasue it directly reads the table information at a specific point in time, this method is usually more efficient. However, it is subject to the GC mechanism, because GC might delete older data versions. If the checkpoint TS is too old, the corresponding table information might have been deleted by GC, making it impossible to read directly.
+- When configuring Drainer, choose whether to read the table information at the checkpoint TS based on actual needs. If data integrity and consistency are priorities and handling a large number of DDL changes is acceptable, it is recommended to set it to `false`. If efficiency and performance are more important, and the checkpoint TS is guaranteed to be after the GC safe point, it is recommended to set it to `true`.
+- Default value: `false`
+
 ### syncer.to
 
 The `syncer.to` section introduces different types of downstream configuration items according to configuration types.
@@ -349,4 +357,4 @@ When the downstream is Kafka, the valid configuration items are as follows:
 * `host`
 * `user`
 * `password`
-* `port`
+* `port`