Preview PR pingcap/docs#19717 and this preview is triggered from commit

pingcap/docs@8272325

markdown-pages/en/tidbcloud/master/TOC.md

@@ -24,7 +24,7 @@
   - [Data Service](/tidb-cloud/data-service-concepts.md) ![BETA](/media/tidb-cloud/blank_transparent_placeholder.png)
   - [Scalability](/tidb-cloud/scalability-concepts.md)
   - High Availability
-    - [Multi-AZ Deployments](/tidb-cloud/high-availability-with-multi-az.md)
+    - [High Availability in TiDB Cloud Dedicated](/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)

markdown-pages/en/tidbcloud/master/tidb-cloud/backup-and-restore-concepts.md

@@ -26,7 +26,7 @@ If you want to choose the restore point as required, that is, to perform point-i
 
 ## Manual backup
 
-Dual region backup is a feature of TiDB Cloud Dedicated that enables you to back up your data to a known state as needed, and then restore to that state at any time.
+Manual backup is a feature of TiDB Cloud Dedicated that enables you to back up your data to a known state as needed, and then restore to that state at any time.
 
 For more information, see [Perform a manual backup](/tidb-cloud/backup-and-restore.md#perform-a-manual-backup).
 

markdown-pages/en/tidbcloud/master/tidb-cloud/data-service-concepts.md

@@ -34,13 +34,15 @@ For more information, see [Get Started with Chat2Query API](/tidb-cloud/use-chat
 Integrating third-party tools with your Data App enhances your applications with advanced natural language processing and artificial intelligence (AI) capabilities provided by third-party tools. This integration enables your applications to perform more complex tasks and deliver intelligent solutions.
 
 Currently, you can integrate third-party tools, such as GPTs and Dify, in the TiDB Cloud console.
+
 For more information, see [Integrate a Data App with Third-Party Tools](/tidb-cloud/data-service-integrations.md).
 
 ## Configuration as Code
 
 TiDB Cloud provides a Configuration as Code (CaC) approach to represent your entire Data App configurations as code using the JSON syntax.
 
 By connecting your Data App to GitHub, TiDB Cloud can use the CaC approach and push your Data App configurations as [configuration files](/tidb-cloud/data-service-app-config-files.md) to your preferred GitHub repository and branch.
+
 If Auto Sync & Deployment is enabled for your GitHub connection, you can also modify your Data App by updating its configuration files on GitHub. After you push the configuration file changes to GitHub, the new configurations will be deployed in TiDB Cloud automatically.
 
 For more information, see [Deploy Data App Automatically with GitHub](/tidb-cloud/data-service-manage-github-connection.md).

markdown-pages/en/tidbcloud/master/tidb-cloud/data-streaming-concepts.md

@@ -7,7 +7,7 @@ summary: Learn about data streaming concepts for TiDB Cloud.
 
 TiDB Cloud lets you stream data changes from your TiDB Cluster to other systems like Kafka, MySQL, and object storage.
 
-Currently, TiDB Cloud supports streaming data to Apache Kafka, MySQL, TiDB Cloud and cloud storage.
+Currently, TiDB Cloud supports streaming data to Apache Kafka, MySQL, TiDB Cloud, and cloud storage.
 
 ## Changefeed
 

markdown-pages/en/tidbcloud/master/tidb-cloud/database-schema-concepts.md

@@ -37,7 +37,7 @@ Each table consists of rows and columns. Each value in a row belongs to a specif
 
 ### System table
 
-- The `mysql` schema contains TiDB system tables. The design is similar to the `mysql` schema in MySQL, where tables such as `mysql.user` can be edited directly. It also contains a number of tables which are extensions to MySQL.
+- The `mysql` schema contains TiDB system tables. The design is similar to the `mysql` schema in MySQL, where tables such as `mysql.user` can be edited directly. It also contains a number of tables that are extensions to MySQL.
 
 - Information Schema provides an ANSI-standard way of viewing system metadata. TiDB also provides a number of custom `INFORMATION_SCHEMA` tables, in addition to the tables included for MySQL compatibility. Many `INFORMATION_SCHEMA` tables have a corresponding `SHOW` command. The benefit of querying `INFORMATION_SCHEMA` is that it is possible to join between tables.
 
@@ -76,6 +76,7 @@ TiDB supports all the data types in MySQL except the `SPATIAL` type. This includ
 ## Indexes
 
 An index is a copy of selected columns in a table. You can create an index using one or more columns of a [table](/develop/dev-guide-schema-design-overview.md#table). With indexes, TiDB can quickly locate data without having to search every row in a table every time, which greatly improves your query performance.
+
 There are two common types of indexes:
 
 - Primary Key: indexes on the primary key column.
@@ -98,7 +99,7 @@ A composite index is an index built on two or more columns of a table, which is
 
 Invisible indexes are indexes that exist in the database but are hidden from the query optimizer, meaning they are ignored in query plans. In TiDB, invisible indexes are useful for testing and debugging, allowing you to assess the impact of an index on performance without fully dropping it.
 
-Starting from TiDB v8.0.0, you can make the optimizer select invisible indexes by modifying the system variable[`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800).
+Starting from TiDB v8.0.0, you can make the optimizer select invisible indexes by modifying the [`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800) system variable.
 
 ### Clustered indexes
 
@@ -124,7 +125,8 @@ For the following TiDB deployment options, TiDB supports vector data types and v
 
 - TiDB Self-Managed v8.4.0 or later versions
 
-In TiDB, a *vector index* is a specialized index designed for efficient approximate nearest neighbor (ANN) searches over columns containing vector data. Vector indexes, particularly the HNSW (Hierarchical Navigable Small World) algorithm, allow K-nearest neighbors (KNN) searches to identify the closest data points in a vector space quickly. This significantly speeds up query performance, enabling results in milliseconds compared to brute-force methods.
+In TiDB, a vector index is a specialized index designed for efficient approximate nearest neighbor (ANN) searches over columns containing vector data. Vector indexes, particularly the HNSW (Hierarchical Navigable Small World) algorithm, allow K-nearest neighbors (KNN) searches to identify the closest data points in a vector space quickly. This significantly speeds up query performance, enabling results in milliseconds compared to brute-force methods.
+
 Vector indexes rely on TiFlash replicas for data storage and search functionality. Before creating and using vector indexes, make sure that TiFlash nodes are available in your cluster.
 
 ## Constraints
@@ -134,6 +136,7 @@ TiDB supports almost the same constraints as MySQL.
 ### NOT NULL constraints
 
 A `NOT NULL` constraint ensures that a column cannot contain `NULL` values.
+
 When a column is defined with the `NOT NULL` constraint, TiDB ensures that any attempt to insert or update a row with a `NULL` value in that column will result in an error. This behavior is consistent with MySQL's implementation of `NOT NULL` constraints.
 
 ### CHECK constraints
@@ -153,13 +156,14 @@ Unique constraints mean that all non-null values in a unique index and a primary
 A FOREIGN KEY is a database constraint that enforces referential integrity between two tables by linking a column in one table (the child table) to a column in another table (the parent table). This ensures that the values in the foreign key column of the child table match values in the primary or unique key column of the parent table. For example, a record in an `orders` table might have a foreign key linking to a customer in a `customers` table, which ensures that each order is associated with a valid customer.
 
 Starting from v6.6.0, TiDB supports foreign key constraints as an experimental feature. This feature allows cross-table referencing of related data and helps maintain data consistency by enforcing referential integrity. However, it is important to note that this feature is experimental and not recommended for production environments due to potential performance issues, especially with large data volumes.
+
 For more information, see [FOREIGN KEY constraints](/foreign-key.md).
 
 ## Views
 
 A view acts as a virtual table, whose schema is defined by the `SELECT` statement that creates the view. Using views has the following benefits:
 
-- Exposing only safe fields and data to users to ensure security of sensitive fields and data stored in the underlying table.
+- Exposing only safe fields and data to users to ensure the security of sensitive fields and data stored in the underlying table.
 
 - Defining complex queries that frequently appear as views to make complex queries easier and more convenient.
 

markdown-pages/en/tidbcloud/master/tidb-cloud/high-availability-with-multi-az.md

@@ -1,22 +1,22 @@
 ---
-title: High Availability with Multi-AZ Deployments
-summary: TiDB Cloud supports high availability with Multi-AZ deployments.
+title: High Availability in TiDB Cloud Dedicated
+summary: TiDB Cloud Dedicated supports high availability with Multi-AZ deployments.
 ---
 
-# High Availability with Multi-AZ Deployments
+# High Availability in TiDB Cloud Dedicated
 
 TiDB uses the Raft consensus algorithm to ensure that data is highly available and safely replicated throughout storage in Raft Groups. Data is redundantly copied between storage nodes and placed in different availability zones to protect against machine or data center failures. With automatic failover, TiDB ensures that your service is always on.
 
-TiDB Cloud clusters consist of three major components: TiDB node, TiKV node, and TiFlash node. The highly availability implementation of each component for TiDB Cloud Dedicated is as follows:
+TiDB Cloud Dedicated clusters consist of three major components: TiDB node, TiKV node, and TiFlash node. The highly availability implementation of each component for TiDB Cloud Dedicated is as follows:
 
 * **TiDB node**
 
-    TiDB is for computing only and does not store data. It is horizontally scalable. TiDB Cloud deploys TiDB nodes evenly to different availability zones in a region. When a user executes a SQL request, the request first passes through a load balancer deployed across availability zones, and then the load balancer distributes the request to different TiDB nodes for execution. It is recommended that each TiDB Cloud cluster has at least two TiDB nodes for high availability.
+    TiDB is for computing only and does not store data. It is horizontally scalable. TiDB Cloud Dedicated deploys TiDB nodes evenly to different availability zones in a region. When a user executes a SQL request, the request first passes through a load balancer deployed across availability zones, and then the load balancer distributes the request to different TiDB nodes for execution. It is recommended that each TiDB Cloud Dedicated cluster has at least two TiDB nodes for high availability.
 
 * **TiKV node**
 
-    [TiKV](https://docs.pingcap.com/tidb/stable/tikv-overview) is the row-based storage layer of TiDB Cloud cluster with horizontal scalability. On TiDB Cloud, the minimum number of TiKV nodes for a cluster is 3. TiDB Cloud deploys TiKV nodes evenly to all availability zones (at least 3) in the region you select to achieve durability and high availability. In a typical 3-replica setup, your data is distributed evenly among the TiKV nodes across all availability zones and is persisted to the disk of each TiKV node.
+    [TiKV](https://docs.pingcap.com/tidb/stable/tikv-overview) is the row-based storage layer of TiDB Cloud Dedicated cluster with horizontal scalability. The minimum number of TiKV nodes for a TiDB Cloud Dedicated cluster is 3. TiDB Cloud Dedicated deploys TiKV nodes evenly to all availability zones (at least 3) in the region you select to achieve durability and high availability. In a typical 3-replica setup, your data is distributed evenly among the TiKV nodes across all availability zones and is persisted to the disk of each TiKV node.
 
 * **TiFlash node**
 
-    [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview), as a columnar storage extension of TiKV, is the key component that makes TiDB essentially a Hybrid Transactional/Analytical Processing (HTAP) database. In TiFlash, the columnar replicas are asynchronously replicated according to the Raft Learner consensus algorithm. TiDB Cloud deploys TiFlash nodes evenly to different availability zones in a region. It is recommended that you configure at least two TiFlash nodes in each TiDB Cloud cluster and create at least two replicas of the data for high availability in your production environment.
+    [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview), as a columnar storage extension of TiKV, is the key component that makes TiDB essentially a Hybrid Transactional/Analytical Processing (HTAP) database. In TiFlash, the columnar replicas are asynchronously replicated according to the Raft Learner consensus algorithm. TiDB Cloud Dedicated deploys TiFlash nodes evenly to different availability zones in a region. It is recommended that you configure at least two TiFlash nodes in each TiDB Cloud Dedicated cluster and create at least two replicas of the data for high availability in your production environment.

markdown-pages/en/tidbcloud/master/tidb-cloud/monitoring-concepts.md

@@ -9,7 +9,7 @@ Monitoring in TiDB Cloud provides tools and integrations that enable you to over
 
 ## Built-in metrics
 
-Built-in Metrics refer to a full set of standard metrics of your cluster that TiDB Cloud collects and presents on the Metrics page. With these metrics, you can easily identify performance issues and determine whether your current database deployment meets your requirements.
+Built-in metrics refer to a full set of standard metrics of your cluster that TiDB Cloud collects and presents on the Metrics page. With these metrics, you can easily identify performance issues and determine whether your current database deployment meets your requirements.
 
 For more information, see [TiDB Cloud Built-in Metrics](/tidb-cloud/built-in-monitoring.md).
 
@@ -29,7 +29,7 @@ For more information, see [TiDB Cloud Built-in Alerting](/tidb-cloud/monitor-bui
 
 ## Cluster events
 
-In TiDB Cloud, an *event* indicates a change in your TiDB Cloud cluster. TiDB Cloud logs the historical events at the cluster level to help you track cluster activities. You can view the logged events on the **Events** page, including the event type, status, message, trigger time, and trigger user.
+In TiDB Cloud, an event indicates a change in your TiDB Cloud cluster. TiDB Cloud logs the historical events at the cluster level to help you track cluster activities. You can view the logged events on the **Events** page, including the event type, status, message, trigger time, and trigger user.
 
 For more information, see [TiDB Cloud Cluster Event](/tidb-cloud/tidb-cloud-events.md).
 
@@ -44,4 +44,5 @@ TiDB Cloud lets you integrate any of the following third-party metrics services
 - New Relic integration
 
 Currently, these third-party metrics integrations are in beta.
+
 For more information, see [Third-Party Metrics Integration (Beta)](/tidb-cloud/third-party-monitoring-integrations.md).

markdown-pages/en/tidbcloud/master/tidb-cloud/scalability-concepts.md

@@ -9,7 +9,7 @@ TiDB Cloud Dedicated lets you adjust its compute and storage resources separatel
 
 > **Note:**
 >
-> [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) scales automatically based on your application's workload changes. However, you cannot manually scale a TiDB Cloud Serverless cluster.
+> [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) scales automatically based on your application's workload changes. However, you cannot manually scale a TiDB Cloud Serverless cluster.
 
 > **Tip:**
 >
@@ -26,22 +26,18 @@ A combination of both vertical and horizontal scaling is also supported in TiDB
 
 ## TiDB scalability
 
-TiDB is for computing only and does not store data. You can configure node number, vCPU, and RAM for TiDB.
+TiDB is for computing only and does not store data. You can configure the node number, vCPU, and RAM for TiDB.
 
 In general, TiDB performance increases linearly with the number of TiDB nodes.
 
-## Storage scalability
-
-In TiDB Cloud, you can scale both row-based and columnar data storage on-demand to meet changing workloads and performance requirements
-
 ## TiKV scalability
 
-TiKV is responsible for storing row-based data. You can configure node number, vCPU and RAM, and storage for TiKV. The number of TiKV nodes should be at least 1 set (3 nodes in 3 different Available Zones) and increase by 3 nodes.
+TiKV is responsible for storing row-based data. You can configure the node number, vCPU and RAM, and storage for TiKV. The number of TiKV nodes should be at least 1 set (3 nodes in 3 different available zones) and increase by 3 nodes.
 
 TiDB Cloud deploys TiKV nodes evenly to 3 available zones in the region you select to achieve durability and high availability. In a typical 3-replica setup, your data is distributed evenly among the TiKV nodes across all availability zones and is persisted to the disk of each TiKV node. Although TiKV is mainly used for data storage, the performance of the TiKV node also varies depending on different workloads.
 
 ## TiFlash scalability
 
-TiFlash is responsible for storing columnar data. TiFlash synchronizes data from TiKV in real time and supports real-time analytics workloads right out of the box. You can configure node number, vCPU and RAM, and storage for TiFlash.
+TiFlash is responsible for storing columnar data. TiFlash synchronizes data from TiKV in real time and supports real-time analytics workloads right out of the box. You can configure the node number, vCPU and RAM, and storage for TiFlash.
 
 TiDB Cloud deploys TiFlash nodes evenly to different availability zones in a region. It is recommended that you configure at least two TiFlash nodes in each TiDB Cloud cluster and create at least two replicas of the data for high availability in your production environment.

markdown-pages/en/tidbcloud/master/tidb-cloud/security-concepts.md

@@ -138,7 +138,6 @@ TiDB Cloud manages users and resources with a hierarchical structure: organizati
     - Project 3
         - Cluster 5
         - Cluster 6
-
 ```
 
 ### Key features
@@ -201,7 +200,7 @@ TiDB Cloud safeguards static data with advanced encryption capabilities, ensurin
 
 **Customer-Managed Encryption Key (CMEK)**
 
-- Provides organizations full control over encryption for Dedicated clusters.
+- Provides organizations full control over encryption for TiDB Cloud Dedicated clusters.
 
 - Encrypts static data and backups with CMEK keys when enabled.