diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index b216609f8acb4..0ebbcfbdb4755 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -8,6 +8,23 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes','/ai/v This page lists the release notes of [TiDB Cloud](https://www.pingcap.com/tidb-cloud/) in 2026. +## October 27, 2026 + +**General changes** + +- **TiDB Cloud Essential** + + - TiDB Cloud Essential now supports **Regional High Availability** (public preview) in `Tokyo (ap-northeast-1)`, with support for additional regions rolling out gradually. + + When creating a new TiDB Cloud Essential instance in a supported region, you can choose between **Zonal** (single Availability Zone) and **Regional** (multiple Availability Zones) high availability. + + Regional High Availability provides enhanced resilience against Availability Zone failures. For TiDB Cloud Essential, the new regional RCU price is now higher than the previous price, while zonal RCU pricing remains unchanged. The new Regional price takes effect as follows: + + - For TiDB Cloud Essential instances with Regional High Availability created before October 26, 2026, the new pricing will take effect in January 2027. + - For TiDB Cloud Essential instances created on or after October 26, 2026, the new pricing applies immediately upon creation. + + For RCU pricing details, see [TiDB Cloud Essential Pricing Details](https://www.pingcap.com/tidb-cloud-essential-pricing-details/). + ## October 20, 2026 **General changes** diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md index 2df2811cb8bd7..2011b43c0cbf9 100644 --- a/tidb-cloud/serverless-high-availability.md +++ b/tidb-cloud/serverless-high-availability.md @@ -18,24 +18,11 @@ TiDB ensures high availability and data durability using the Raft consensus algo TiDB Cloud extends these capabilities with zonal high availability and regional high availability to meet different operational requirements. - - -> **Note:** -> -> - For {{{ .starter }}} and Essential instances, only zonal high availability is enabled, and it is not configurable. -> - For {{{ .premium }}} instances, only regional high availability is enabled and is not configurable. - - - - - > **Note:** > > - For {{{ .starter }}} instances, only zonal high availability is enabled, and it is not configurable. > - For {{{ .premium }}} instances, only regional high availability is enabled and is not configurable. -> - For {{{ .essential }}} instances hosted in the AWS Tokyo (ap-northeast-1) region, regional high availability is enabled by default. You can change it to zonal high availability as needed during {{{ .essential }}} instance creation. For {{{ .essential }}} instances hosted in other regions, only zonal high availability is enabled, and it is not configurable. - - +> - For {{{ .essential }}} instances hosted in the AWS `Tokyo (ap-northeast-1)` region, regional high availability is enabled by default. You can change it to zonal high availability as needed during {{{ .essential }}} instance creation. For {{{ .essential }}} instances hosted in other regions, only zonal high availability is enabled, and it is not configurable. - **Zonal high availability**: This option places all nodes within a single availability zone, reducing network latency. It ensures high availability without requiring application-level redundancy across zones, making it suitable for applications that prioritize low latency within a single zone. For more information, see [Zonal high availability architecture](#zonal-high-availability-architecture). @@ -99,17 +86,7 @@ The gateway and computing layers are stateless, so failover involves restarting ## Regional high availability architecture - - -When you create a {{{ .essential }}} or {{{ .premium }}} instance with regional high availability, critical OLTP (Online Transactional Processing) workload components, such as PD and TiKV, are deployed across multiple availability zones to ensure redundant replication and maximizing availability. During normal operations, components like Gateway, TiDB, and TiFlash compute/write nodes are hosted in the primary availability zone. These components in data plane offer infrastructure redundancy through virtual machine pools, which minimizes failover time and network latency due to colocation. - - - - - -When you create a {{{ .premium }}} instance with regional high availability, critical OLTP (Online Transactional Processing) workload components, such as PD and TiKV, are deployed across multiple availability zones to ensure redundant replication and maximize availability. During normal operations, components like Gateway, TiDB, and TiFlash compute/write nodes are hosted in the primary availability zone. These components in the data plane offer infrastructure redundancy through virtual machine pools, which minimizes failover time and network latency due to colocation. - - +When you create a {{{ .essential }}} or {{{ .premium }}} instance with regional high availability, critical OLTP (Online Transactional Processing) workload components, such as PD and TiKV, are deployed across multiple availability zones to ensure redundant replication and maximize availability. During normal operations, components like Gateway, TiDB, and TiFlash compute/write nodes are hosted in the primary availability zone. These components in data plane offer infrastructure redundancy through virtual machine pools, which minimizes failover time and network latency due to colocation. > **Note:** >