From beb5938a54185abb0d0824964cd28c0c2319bd62 Mon Sep 17 00:00:00 2001
From: WenyXu <wenymedia@gmail.com>
Date: Fri, 19 Sep 2025 16:58:49 +0800
Subject: [PATCH 1/6] refactor: refactor Read Replica documentation structure

---
 .../configure-datanode-groups.md              |   2 +-
 docs/enterprise/read-replica.md               | 173 -----------------
 .../read-replicas/manage-read-replicas.md     | 181 +++++++++++++++++
 docs/enterprise/read-replicas/overview.md     |  53 +++++
 .../read-replicas/query-read-replicas.md      | 100 ++++++++++
 .../current.json                              |   4 +
 .../configure-datanode-groups.md              |   2 +-
 .../read-replicas/manage-read-replicas.md     | 183 ++++++++++++++++++
 .../enterprise/read-replicas/overview.md      |  53 +++++
 .../read-replicas/query-read-replicas.md      |  95 +++++++++
 sidebars.ts                                   |  10 +-
 11 files changed, 680 insertions(+), 176 deletions(-)
 delete mode 100644 docs/enterprise/read-replica.md
 create mode 100644 docs/enterprise/read-replicas/manage-read-replicas.md
 create mode 100644 docs/enterprise/read-replicas/overview.md
 create mode 100644 docs/enterprise/read-replicas/query-read-replicas.md
 create mode 100644 i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/manage-read-replicas.md
 create mode 100644 i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md
 create mode 100644 i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md

diff --git a/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md b/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
index 8a0fe6f4b..394b82ff3 100644
--- a/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
+++ b/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
@@ -97,4 +97,4 @@ weny-cluster-meta-58977b7897-8k2sf           1/1     Running   0          90s
 
 - For best performance, it is recommended to [Configure frontend groups](/user-guide/deployments-administration/deploy-on-kubernetes/configure-frontend-groups.md), which ensures complete separation of read and write traffic, achieving maximum isolation. 
 
-- Add Read Replica for your table, please refer to [Read Replica](/enterprise/read-replica.md).
\ No newline at end of file
+- Add Read Replica for your table, please refer to [Read Replica](/enterprise/read-replicas/overview.md).
\ No newline at end of file
diff --git a/docs/enterprise/read-replica.md b/docs/enterprise/read-replica.md
deleted file mode 100644
index 9e66408fc..000000000
--- a/docs/enterprise/read-replica.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-keywords: [enterprise, cluster, read replica, leader region, follower region]
-description: Overview, principles, and how-tos of read replica feature in GreptimeDB Enterprise.
----
-
-# Read Replica
-
-Read Replica is a key feature in GreptimeDB's Enterprise Cluster Edition, designed to enhance the overall read-write performance and scalability of the database system.
-
-In the Read Replica mechanism, clients write data to the Leader Region, which then synchronizes the data to Follower Regions. Follower Regions serve as read-only replicas of the Leader Region. Since Leader and Follower Regions are deployed on different Datanode nodes, read and write requests are effectively isolated, preventing resource contention and delivering a smoother experience:
-
-<p align="center">
-    <img src="/read-replica-overview.png" alt="read-replica-overview" width="600"/>
-</p>
-
-:::tip NOTE
-The Read Replica feature is exclusive to the GreptimeDB Enterprise Cluster Edition.
-:::
-
-## Principles
-
-GreptimeDB's Enterprise Cluster Edition leverages its architecture to enable near-zero-cost data synchronization between replicas. Additionally, Read Replicas can access newly written data with minimal latency. Below is a brief explanation of the data synchronization and read mechanisms.
-
-### Data Synchronization
-
-In GreptimeDB, storage and compute resources are disaggregated. All data is stored in SST files on object storage. Thus, synchronizing data between Leader and Follower Regions does not require copying SST files -- only their metadata needs to be synced. Metadata is significantly smaller than SST files, making synchronization effortless. Once metadata is synced, the Read Replica "possesses" the same SST files and can access the data:
-
-![read-replica-data-sync](/read-replica-data-sync.png)
-
-In practice, SST files metadata is persisted in a special manifest file, also stored in object storage. Each manifest file has a unique version number. Synchronizing metadata between Leader and Follower Regions essentially involves syncing this version number -- a simple integer, ensuring minimal overhead. After receiving the version number, the Follower Region fetches the manifest file from object storage, thereby obtaining the SST files metadata generated by the Leader Region.
-
-The manifest version number is synchronized via heartbeats between Regions and Metasrv. The Leader Region includes the version number in its heartbeat to Metasrv, which then forwards it to Follower Regions in their heartbeat responses:
-
-![read-replica-heartbeat](/read-replica-heartbeat.png)
-
-It's easy to see, if there were only SST files synchronization mechanism in place, the delay for Read Replica to access written data would be the sum of the heartbeat intervals between Leader/Follower Regions and Metasrv. For example, with a default 3-second heartbeat interval, Read Replica would only see the data that are written to SST files and flushed to object store 3 to 6 seconds prior. While this suffices for clients with relaxed freshness requirements, additional mechanisms are needed for near-real-time reads.
-
-### Data Read
-
-Newly written data are stored in the Leader Region’s memtable. To access the latest data, Follower Region needs to request the memtable data from the Leader Region. By combining this with SST files data (obtained via data sync above), the Follower Region provides clients with a complete dataset, including the most recent writes:
-
-<p align="center">
-    <img src="/read-replica-data-read.png" alt="read-replica-data-read" width="600"/>
-</p>
-
-Follower Region fetch memtable data from Leader Region via an internal gRPC interface. While this imposes some read load on the Leader Region, the impact is minimal since the memtable data resides in memory and is finite in size.
-
-## Adding Read Replicas
-
-Adding a Read Replica is as simple as executing one SQL command:
-
-```sql
-ADMIN ADD_TABLE_FOLLOWER(<table_name>, <follower_datanodes>)
-```
-
-This is the function in GreptimeDB for adding Read Replicas. The parameters are:
-
-- `table_name`: The name of the table to add Read Replicas to.
-- `follower_datanodes`: A comma-separated list of Datanode IDs where Follower Regions should be placed.
-
-Next is an example to illustrate steps to add Read Replicas to a table.
-
-First start a GreptimeDB Enterprise Cluster with 3 Datanodes. Then create a table:
-
-```sql
-CREATE TABLE foo (
-  ts TIMESTAMP TIME INDEX,
-  i INT PRIMARY KEY,
-  s STRING,
-) PARTITION ON COLUMNS ('i') (
-  i <= 0,
-  i > 0,
-);
-```
-
-Through the `information_schema`, we can find the Regions' information:
-
-```sql
-SELECT table_name, region_id, peer_id, is_leader FROM information_schema.region_peers WHERE table_name = 'foo';
-
-+------------+---------------+---------+-----------+
-| table_name | region_id     | peer_id | is_leader |
-+------------+---------------+---------+-----------+
-| foo        | 4402341478400 |       1 | Yes       |
-| foo        | 4402341478401 |       2 | Yes       |
-+------------+---------------+---------+-----------+
-```
-
-This shows two Leader Regions on Datanodes 1 and 2.
-
-Then to add Read Replicas:
-
-```sql
-ADMIN ADD_TABLE_FOLLOWER('foo', '0,1,2');
-```
-
-After the Read Replicas are added, find the Regions' information again:
-
-```sql
-SELECT table_name, region_id, peer_id, is_leader FROM information_schema.region_peers WHERE table_name = 'foo';
-
-+------------+---------------+---------+-----------+
-| table_name | region_id     | peer_id | is_leader |
-+------------+---------------+---------+-----------+
-| foo        | 4402341478400 |       1 | Yes       |
-| foo        | 4402341478400 |       0 | No        |
-| foo        | 4402341478401 |       2 | Yes       |
-| foo        | 4402341478401 |       1 | No        |
-+------------+---------------+---------+-----------+
-```
-
-Now, Follower Regions can be found on Datanodes 0 and 1.
-
-## Using Read Replicas
-
-Clients can specify whether to read from Read Replicas like this (for JDBC connections):
-
-```sql
--- Directly read from the Follower Regions (errors if none exist):
-SET READ_PREFERENCE='follower';
-
--- Prefer Follower Regions, fallback to Leader Regions if unavailable (won't error out if there're no Follower Regions):
-SET READ_PREFERENCE='follower_preferred';
-
--- Directly read from the Leader Regions:
-SET READ_PREFERENCE='leader';
-```
-
-We still use the table in the above example to show the reads from Follower Replicas. First insert some data:
-
-```sql
-INSERT INTO foo (ts, i, s) VALUES (1, -1, 's1'), (2, 0, 's2'), (3, 1, 's3');
-```
-
-Set the read preference to "follower" only:
-
-```sql
-SET READ_PREFERENCE='follower';
-```
-
-Read the data:
-
-```sql
-SELECT * FROM foo ORDER BY ts;
-
-+----------------------------+------+------+
-| ts                         | i    | s    |
-+----------------------------+------+------+
-| 1970-01-01 00:00:00.001000 |   -1 | s1   |
-| 1970-01-01 00:00:00.002000 |    0 | s2   |
-| 1970-01-01 00:00:00.003000 |    1 | s3   |
-+----------------------------+------+------+
-```
-
-How to verify the reads are really executed by Follower Replicas? We can use the `EXPLAIN ANALYZE`:
-
-```sql
-EXPLAIN ANALYZE SELECT * FROM foo ORDER BY ts;
-```
-
-A non-zero "`other_ranges`" in the output confirms that Follower Region does handle the reads. If using the `VERBOSE` mode:
-
-```sql
-EXPLAIN ANALYZE VERBOSE SELECT * FROM foo ORDER BY ts;
-```
-
-There is more detailed output like this:
-
-```plaintext
-extension_ranges: [LeaderMemtableRange{leader: Peer { id: 1, addr: "192.168.50.189:14101" }, num_rows: 2, time_range: (1::Millisecond, 2::Millisecond)
-```
-
-Which can't be found if the reads are executed by Leader Replicas.
diff --git a/docs/enterprise/read-replicas/manage-read-replicas.md b/docs/enterprise/read-replicas/manage-read-replicas.md
new file mode 100644
index 000000000..ba57c3140
--- /dev/null
+++ b/docs/enterprise/read-replicas/manage-read-replicas.md
@@ -0,0 +1,181 @@
+---
+keywords: [enterprise, cluster, read replicas, leader region, follower region]
+description: An overview, key concepts, and step-by-step guides for managing read replicas in GreptimeDB Enterprise.
+---
+
+# Manage Read Replicas
+
+This guide explains how to manage **Read Replicas (follower regions)** in GreptimeDB Enterprise, including how to add and remove read replicas at both the table and region levels, inspect the current regions distribution with the `SHOW REGION`, and apply placement constraints and recommended best practices for performance.
+
+## Adding Read Replicas to a Table
+
+Adding a Read Replica is as simple as executing one SQL command:
+
+```sql
+ADMIN ADD_TABLE_FOLLOWER(<table_name>)
+```
+
+Read Replica peers for each region are allocated based on the workload types of the datanodes. **For optimal performance, it is strongly recommended to [configure Datanode groups](/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md) to separate read and write workloads into different datanode groups.**
+
+This is the function in GreptimeDB for adding read replicas to. The parameters are:
+
+- `table_name`: The name of the table to add read replicas to.
+
+Next is an example to illustrate steps to add read replicas to a table.
+
+First start a GreptimeDB Enterprise Cluster with 3 Datanodes. Then create a table:
+
+```sql
+CREATE TABLE foo (
+  ts TIMESTAMP TIME INDEX,
+  i INT PRIMARY KEY,
+  s STRING,
+) PARTITION ON COLUMNS ('i') (
+  i <= 0,
+  i > 0,
+);
+```
+
+
+Using the `SHOW REGION`, we can find the regions distribution information:
+
+```sql
+SHOW REGION FROM foo;
+
++-------+---------------+------+--------+
+| Table | Region        | Peer | Leader |
++-------+---------------+------+--------+
+| foo   | 4398046511104 |    0 | Yes    |
+| foo   | 4398046511105 |    1 | Yes    |
++-------+---------------+------+--------+
+```
+
+This shows two write replicas (leader regions) on Datanodes `1` and `2`.
+
+Then to add read replicas (Follower regions):
+
+```sql
+ADMIN ADD_TABLE_FOLLOWER('foo');
+```
+
+After the read replicas are added, find the regions distribution information:
+
+```sql
+SHOW REGION FROM foo;
+
++-------+---------------+------------+--------+
+| Table | Region        | Peer       | Leader |
++-------+---------------+------------+--------+
+| foo   | 4398046511104 |          0 | Yes    |
+| foo   | 4398046511104 | 4294967296 | No     |
+| foo   | 4398046511105 |          1 | Yes    |
+| foo   | 4398046511105 | 4294967297 | No     |
++-------+---------------+------------+--------+
+```
+
+Now, read replicas can be found on Datanode `4294967296` and `4294967297`.
+
+## Removing Read Replicas from a Table
+
+Removing a Read Replica is as simple as executing one SQL command:
+
+```sql
+ADMIN REMOVE_TABLE_FOLLOWER(<table_name>)
+```
+
+This is the function in GreptimeDB for removing read replicas from a table. The parameters are:
+
+- `table_name`: The name of the table to remove read replicas from.
+
+This command removes **the most recently added read replica' peers from each region**.
+
+For example, before running the command:
+
+```sql
+SHOW REGION FROM foo;
++-------+---------------+------------+--------+
+| Table | Region        | Peer       | Leader |
++-------+---------------+------------+--------+
+| foo   | 4398046511104 |          0 | Yes    |
+| foo   | 4398046511104 | 4294967296 | No     |
+| foo   | 4398046511104 | 4294967297 | No     |
+| foo   | 4398046511105 |          1 | Yes    |
+| foo   | 4398046511105 | 4294967296 | No     |
+| foo   | 4398046511105 | 4294967297 | No     |
++-------+---------------+------------+--------+
+```
+
+Here, region `4398046511104` has two read replicas on peers (`4294967296`, `4294967297`), and region `4398046511105` also has two read replicas on peers (`4294967296`, `4294967297`).
+After executing:
+
+```sql
+ADMIN REMOVE_TABLE_FOLLOWER('foo');
++------------------------------------+
+| ADMIN REMOVE_TABLE_FOLLOWER('foo') |
++------------------------------------+
+|                                  0 |
++------------------------------------+
+```
+
+The most recently added read replicas' peers of each region are removed:
+
+* Region `4398046511104`: removed read replica on peer `4294967297`.
+* Region `4398046511105`: removed read replica on peer `4294967296`.
+
+Result:
+
+```sql
+SHOW REGION FROM foo;
++-------+---------------+------------+--------+
+| Table | Region        | Peer       | Leader |
++-------+---------------+------------+--------+
+| foo   | 4398046511104 |          0 | Yes    |
+| foo   | 4398046511104 | 4294967296 | No     |
+| foo   | 4398046511105 |          1 | Yes    |
+| foo   | 4398046511105 | 4294967297 | No     |
++-------+---------------+------------+--------+
+```
+
+## Adding Read Replica to a Region
+```sql
+ADMIN ADD_REGION_FOLLOWER(<region_id>, <datanode_id>)
+```
+
+This is the function in GreptimeDB for adding read replicas to a region. The parameters are:
+
+- `region_id`: The id of the region to add Read Replica to.
+- `datanode_id`: The id of the datanode to add Read Replica to.
+
+A read replica and a write replica cannot be placed on the same datanode. Additionally, each datanode can host only one read replica per region.
+
+Example:
+
+```sql
+-- Add a read replica for region 4398046511104 on datanode 2
+ADMIN ADD_REGION_FOLLOWER(4398046511104, 2);
+```
+
+If the specified datanode already hosts a read replica for that region, or is the write replica (leader) of that region, the command will be rejected.
+
+## Removing Read Replica from a Region
+```sql
+ADMIN REMOVE_REGION_FOLLOWER(<region_id>, <datanode_id>)
+```
+
+This is the function in GreptimeDB for removing read replicas from a region. The parameters are:
+
+- `region_id`: The id of the region to remove read replica from.
+- `datanode_id`: The id of the datanode to remove read replica from.
+
+
+Example:
+
+```sql
+-- Remove the read replica on datanode 2 for region 4398046511104
+ADMIN REMOVE_REGION_FOLLOWER(4398046511104, 2);
+```
+
+
+## Next steps
+
+* [Query Read Replicas](/enterprise/read-replicas/query-read-replicas.md)
\ No newline at end of file
diff --git a/docs/enterprise/read-replicas/overview.md b/docs/enterprise/read-replicas/overview.md
new file mode 100644
index 000000000..bac1f4db8
--- /dev/null
+++ b/docs/enterprise/read-replicas/overview.md
@@ -0,0 +1,53 @@
+---
+keywords: [enterprise, cluster, read replica, leader region, follower region]
+description: Overview, principles, and how-tos of read replica feature in GreptimeDB Enterprise.
+---
+
+# Overview
+
+Read Replica is a key feature in GreptimeDB's Enterprise Cluster Edition, designed to enhance the overall read-write performance and scalability of the database system.
+
+In the Read Replica mechanism, clients write data to the **Leader Region (write replica)**, which then synchronizes the data to **Follower Regions (read replicas)**. Follower Regions serve as read-only replicas of the Leader Region. By [configuring Datanode groups](/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md), Leader Regions and Follower Regions can be deployed on different Datanode nodes, read and write requests are effectively isolated, preventing resource contention and delivering a smoother experience:
+
+<p align="center">
+    <img src="/read-replica-overview.png" alt="read-replica-overview" width="600"/>
+</p>
+
+::::tip NOTE
+The Read Replica feature is exclusive to the GreptimeDB Enterprise Cluster Edition.
+::::
+
+## Principles
+
+GreptimeDB's Enterprise Cluster Edition leverages its architecture to enable near-zero-cost data synchronization between replicas. Additionally, Read Replicas can access newly written data with minimal latency. Below is a brief explanation of the data synchronization and read mechanisms.
+
+### Data Synchronization
+
+In GreptimeDB, storage and compute resources are disaggregated. All data is stored in SST files on object storage. Thus, synchronizing data between Leader and Follower Regions does not require copying SST files -- only their metadata needs to be synced. Metadata is significantly smaller than SST files, making synchronization effortless. Once metadata is synced, the Read Replica "possesses" the same SST files and can access the data:
+
+![read-replica-data-sync](/read-replica-data-sync.png)
+
+In practice, SST files metadata is persisted in a special manifest file, also stored in object storage. Each manifest file has a unique version number. Synchronizing metadata between Leader and Follower Regions essentially involves syncing this version number -- a simple integer, ensuring minimal overhead. After receiving the version number, the Follower Region fetches the manifest file from object storage, thereby obtaining the SST files metadata generated by the Leader Region.
+
+The manifest version number is synchronized via heartbeats between Regions and Metasrv. The Leader Region includes the version number in its heartbeat to Metasrv, which then forwards it to Follower Regions in their heartbeat responses:
+
+![read-replica-heartbeat](/read-replica-heartbeat.png)
+
+It's easy to see, if there were only SST files synchronization mechanism in place, the delay for Read Replica to access written data would be the sum of the heartbeat intervals between Leader/Follower Regions and Metasrv. For example, with a default 3-second heartbeat interval, Read Replica would only see the data that are written to SST files and flushed to object store 3 to 6 seconds prior. While this suffices for clients with relaxed freshness requirements, additional mechanisms are needed for near-real-time reads.
+
+### Data Read
+
+Newly written data are stored in the Leader Region’s memtable. To access the latest data, Follower Region needs to request the memtable data from the Leader Region. By combining this with SST files data (obtained via data sync above), the Follower Region provides clients with a complete dataset, including the most recent writes:
+
+<p align="center">
+    <img src="/read-replica-data-read.png" alt="read-replica-data-read" width="600"/>
+</p>
+
+Follower Region fetch memtable data from Leader Region via an internal gRPC interface. While this imposes some read load on the Leader Region, the impact is minimal since the memtable data resides in memory and is finite in size.
+
+## Next steps
+
+* [Manage Read Replicas](/enterprise/read-replicas/manage-read-replicas.md)
+* [Query Read Replicas](/enterprise/read-replicas/query-read-replicas.md)
+
+
diff --git a/docs/enterprise/read-replicas/query-read-replicas.md b/docs/enterprise/read-replicas/query-read-replicas.md
new file mode 100644
index 000000000..46fa9865e
--- /dev/null
+++ b/docs/enterprise/read-replicas/query-read-replicas.md
@@ -0,0 +1,100 @@
+---
+keywords: [enterprise, cluster, read replica, leader region, follower region]
+description: Overview, key concepts, and step-by-step instructions for managing and querying read replicas in GreptimeDB Enterprise.
+---
+
+# Query Read Replicas
+
+GreptimeDB allows you to read from **Region Replicas (follower regions)** to reduce load on Write Replicas (Leader regions) and improve query scalability. You can control the read preference through both **SQL** and **HTTP** protocols.
+
+## Read Preference Options
+
+The `READ_PREFERENCE` setting accepts the following values:
+
+* **`leader`**
+  Always read from write replicas.
+
+* **`follower`**
+  Read only from read replicas The query will fail if no read replicas exist.
+
+* **`follower_preferred`**
+  Prefer read replicas but fall back to write replicas if read replicas are unavailable.
+
+## SQL Protocol
+
+You can set the read preference in a SQL session:
+
+```sql
+SET READ_PREFERENCE = 'follower';
+```
+
+---
+
+## HTTP Protocol
+
+For HTTP requests, specify the `X-Greptime-Read-Preference` header.
+
+Example:
+
+```bash
+curl -X POST \
+  -H "Content-Type: application/x-www-form-urlencoded" \
+  -H "X-Greptime-Read-Preference: follower" \
+  -d "sql=select * from monitoring" \
+  http://localhost:4000/v1/sql
+```
+
+---
+
+## Example: Reading from Follower Replicas
+
+Before reading from Follower Replicas, you need to add Read Replicas to the table. See [Replica Management](/enterprise/read-replicas/replica-management.md) for more details.
+
+Insert some data into a table:
+
+```sql
+INSERT INTO foo (ts, i, s)
+VALUES
+  (1, -1, 's1'),
+  (2, 0, 's2'),
+  (3, 1, 's3');
+```
+
+Set the read preference to read replicas:
+
+```sql
+SET READ_PREFERENCE = 'follower';
+```
+
+Query the data:
+
+```sql
+SELECT * FROM foo ORDER BY ts;
+
++----------------------------+------+------+
+| ts                         | i    | s    |
++----------------------------+------+------+
+| 1970-01-01 00:00:00.001000 |   -1 | s1   |
+| 1970-01-01 00:00:00.002000 |    0 | s2   |
+| 1970-01-01 00:00:00.003000 |    1 | s3   |
++----------------------------+------+------+
+```
+
+---
+
+## Verifying Follower Reads
+
+To confirm that queries are served by read replicas, use `EXPLAIN ANALYZE`:
+
+```sql
+EXPLAIN ANALYZE SELECT * FROM foo ORDER BY ts;
+```
+
+* A **non-zero `other_ranges`** value indicates read replicas were involved.
+* With the `VERBOSE` option, you can see details like this:
+
+```plaintext
+extension_ranges: [LeaderMemtableRange{leader: Peer { id: 1, addr: "192.168.50.189:14101" }, num_rows: 2, time_range: (1::Millisecond, 2::Millisecond) ...
+```
+
+If the query runs only on leaders, this `extension_ranges` section will not appear.
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current.json b/i18n/zh/docusaurus-plugin-content-docs/current.json
index 5ed7ea358..c9876b0a6 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current.json
+++ b/i18n/zh/docusaurus-plugin-content-docs/current.json
@@ -226,5 +226,9 @@
   "sidebar.docs.category.Vector Storage": {
     "message": "向量存储",
     "description": "The label for category Vector Storage in sidebar docs"
+  },
+  "sidebar.docs.category.Read Replicas": {
+    "message": "读副本",
+    "description": "The label for category Read Replicas in sidebar docs"
   }
 }
\ No newline at end of file
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
index b9a8cbbe0..ee3bfbfe3 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
@@ -96,4 +96,4 @@ weny-cluster-meta-58977b7897-8k2sf           1/1     Running   0          90s
 
 - 为了获得最佳性能，建议[配置 frontend 组](/user-guide/deployments-administration/deploy-on-kubernetes/configure-frontend-groups.md)，这确保读写流量的完全分离，实现最大隔离。
 
-- 为你的表添加读副本，请参阅[读副本](/enterprise/read-replica.md)。
+- 为你的表添加读副本，请参阅[读副本](/enterprise/read-replicas/overview.md)。
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/manage-read-replicas.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/manage-read-replicas.md
new file mode 100644
index 000000000..69cdf5b59
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/manage-read-replicas.md
@@ -0,0 +1,183 @@
+---
+keywords: [企业版, 集群, 读副本, 管理, region, follower]
+description: 在 GreptimeDB 企业版中管理读副本的概览、关键概念与操作指南。
+---
+
+# 管理读副本
+
+本文介绍如何在 GreptimeDB 企业版中管理读副本，包括在表与 Region 级别添加/移除读副本、使用 `SHOW REGION` 查看副本分布，以及放置约束与性能最佳实践建议。
+
+## 为表添加读副本
+
+添加读副本只需一条 SQL：
+
+```sql
+ADMIN ADD_TABLE_FOLLOWER(<table_name>)
+```
+
+每个 Region 的 Follower 节点会基于 Datanode 的工作负载类型进行分配。**为获得最佳性能，强烈建议先[配置 Datanode 分组](/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md)，将读与写工作负载分别放置在不同的 Datanode 组中。**
+
+该函数的参数：
+
+- `table_name`：需要添加读副本的表名。
+
+示例步骤：
+
+先启动一个包含 3 个 Datanode 的企业集群，然后建表：
+
+```sql
+CREATE TABLE foo (
+  ts TIMESTAMP TIME INDEX,
+  i INT PRIMARY KEY,
+  s STRING,
+) PARTITION ON COLUMNS ('i') (
+  i <= 0,
+  i > 0,
+);
+```
+
+使用 `SHOW REGION` 查看当前 Region 分布：
+
+```sql
+SHOW REGION FROM foo;
+
++-------+---------------+------+--------+
+| Table | Region        | Peer | Leader |
++-------+---------------+------+--------+
+| foo   | 4398046511104 |    0 | Yes    |
+| foo   | 4398046511105 |    1 | Yes    |
++-------+---------------+------+--------+
+```
+
+上述结果表明在 Datanode `0` 与 `1` 上各有一个写副本 Region。
+
+接着添加读副本：
+
+```sql
+ADMIN ADD_TABLE_FOLLOWER('foo');
+```
+
+再次查看 Region 分布：
+
+```sql
+SHOW REGION FROM foo;
+
++-------+---------------+------------+--------+
+| Table | Region        | Peer       | Leader |
++-------+---------------+------------+--------+
+| foo   | 4398046511104 |          0 | Yes    |
+| foo   | 4398046511104 | 4294967296 | No     |
+| foo   | 4398046511105 |          1 | Yes    |
+| foo   | 4398046511105 | 4294967297 | No     |
++-------+---------------+------------+--------+
+```
+
+现在可以看到读副本已经分配到 Peer `4294967296` 与 `4294967297` 上。
+
+## 从表移除读副本
+
+移除读副本同样只需一条 SQL：
+
+```sql
+ADMIN REMOVE_TABLE_FOLLOWER(<table_name>)
+```
+
+该函数参数：
+
+- `table_name`：要移除读副本的表名。
+
+该命令会从每个 Region 中移除**最近添加的**一个读副本。
+
+示例，执行前：
+
+```sql
+SHOW REGION FROM foo;
++-------+---------------+------------+--------+
+| Table | Region        | Peer       | Leader |
++-------+---------------+------------+--------+
+| foo   | 4398046511104 |          0 | Yes    |
+| foo   | 4398046511104 | 4294967296 | No     |
+| foo   | 4398046511104 | 4294967297 | No     |
+| foo   | 4398046511105 |          1 | Yes    |
+| foo   | 4398046511105 | 4294967296 | No     |
+| foo   | 4398046511105 | 4294967297 | No     |
++-------+---------------+------------+--------+
+```
+
+此时 Region `4398046511104` 与 `4398046511105` 各有两个读副本在 `4294967296`、`4294967297` 节点上。
+
+执行：
+
+```sql
+ADMIN REMOVE_TABLE_FOLLOWER('foo');
++------------------------------------+
+| ADMIN REMOVE_TABLE_FOLLOWER('foo') |
++------------------------------------+
+|                                  0 |
++------------------------------------+
+```
+
+每个 Region 最近添加的读副本被移除：
+
+- Region `4398046511104`：移除了 `4294967297` 节点上的读副本
+- Region `4398046511105`：移除了 `4294967296` 节点上的读副本
+
+结果：
+
+```sql
+SHOW REGION FROM foo;
++-------+---------------+------------+--------+
+| Table | Region        | Peer       | Leader |
++-------+---------------+------------+--------+
+| foo   | 4398046511104 |          0 | Yes    |
+| foo   | 4398046511104 | 4294967296 | No     |
+| foo   | 4398046511105 |          1 | Yes    |
+| foo   | 4398046511105 | 4294967297 | No     |
++-------+---------------+------------+--------+
+```
+
+## 为 Region 添加读副本
+
+```sql
+ADMIN ADD_REGION_FOLLOWER(<region_id>, <datanode_id>)
+```
+
+参数说明：
+
+- `region_id`：需要添加读副本的 Region ID。
+- `datanode_id`：要承载该读副本的 Datanode ID。
+
+同一 Datanode 上不能同时承载同一 Region 的写副本与读副本；且每个 Datanode 对同一 Region 仅能承载一个读副本。
+
+示例：
+
+```sql
+-- 在 Datanode 2 上为 Region 4398046511104 添加一个读副本
+ADMIN ADD_REGION_FOLLOWER(4398046511104, 2);
+```
+
+若目标 Datanode 已存在该 Region 的读副本，或该 Datanode 已存在该 Region 的写副本，则命令会被拒绝。
+
+## 从 Region 移除读副本
+
+```sql
+ADMIN REMOVE_REGION_FOLLOWER(<region_id>, <datanode_id>)
+```
+
+参数说明：
+
+- `region_id`：需要移除读副本的 Region ID。
+- `datanode_id`：要移除的读副本所在的 Datanode ID。
+
+示例：
+
+```sql
+-- 从 Datanode 2 上移除 Region 4398046511104 的读副本
+ADMIN REMOVE_REGION_FOLLOWER(4398046511104, 2);
+```
+
+## 下一步
+
+* [从读副本查询](/enterprise/read-replicas/query-read-replicas.md)
+
+
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md
new file mode 100644
index 000000000..44f2ae9a4
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md
@@ -0,0 +1,53 @@
+---
+keywords: [企业版, 集群, 读副本, leader region, follower region]
+description: GreptimeDB 企业版读副本功能的概述与原理。
+---
+
+# 概述
+
+*读副本 (Read Replica)* 是 GreptimeDB 企业集群版中的一项重要功能，旨在提升系统的整体读写性能与可扩展性。
+
+在读副本机制中，客户端将数据写入写副本 (Leader Region)，随后由 Leader Region 将数据同步到 Follower Region。Follower Region 作为 Leader Region 的只读副本。通过[配置 Datanode 组](/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md)，可以将 Leader Region 与 Follower Region 分别部署在不同的 Datanode 节点上，读写请求能够有效隔离，避免资源争用，从而获得更平滑的读写体验：
+
+<p align="center">
+    <img src="/read-replica-overview.png" alt="read-replica-overview" width="600"/>
+</p>
+
+::::tip NOTE
+读副本功能仅在 GreptimeDB 企业集群版中提供。
+::::
+
+## 原理
+
+GreptimeDB 企业集群版基于存算分离架构，使副本间的数据同步几乎零成本；同时，读副本也能以极低延迟读取到最新写入的数据。下面分别介绍数据同步与数据读取机制。
+
+### 数据同步
+
+在 GreptimeDB 中，计算与存储解耦，所有数据以 SST 文件的形式存放在对象存储中。因此，Leader Region 与 Follower Region 之间无需复制 SST 文件本体，只需同步其元信息即可。元信息相比 SST 文件体量小得多，因而同步开销极低。一旦元信息同步完成，读副本便“拥有”相同的 SST 文件，从而可以读取数据：
+
+![read-replica-data-sync](/read-replica-data-sync.png)
+
+在实现上，SST 文件的元信息持久化在一个特殊的 manifest 文件中（同样位于对象存储）。每个 manifest 文件都有唯一的版本号。Leader Region 与 Follower Region 之间的同步，本质上就是同步这个版本号——一个简单的整数，开销极小。Follower Region 获得版本号后即可从对象存储拉取对应的 manifest 文件，从而获得 Leader Region 生成的 SST 元信息。
+
+manifest 版本号通过 Region 与 Metasrv 之间的心跳进行同步：Leader Region 在发往 Metasrv 的心跳中携带版本号，Metasrv 在回复 Follower Region 的心跳中将其下发：
+
+![read-replica-heartbeat](/read-replica-heartbeat.png)
+
+可以看出，若仅依赖 SST 文件层面的同步，读副本读到新写入数据的延迟约为 Leader Region 与 Follower Region 分别到 Metasrv 的心跳间隔之和。以默认 3 秒心跳为例，读副本通常只能读到 3–6 秒前已写入并 flush 至对象存储的数据。对于对数据“新鲜度”要求不高的场景已足够，但若需要近实时读取，还需配合下述机制。
+
+### 数据读取
+
+最新写入的数据首先保存在 Leader Region 的 memtable 中。为了读到这些最新数据，Follower Region 需要向 Leader Region 请求 memtable 数据，并与自身通过前述同步机制获得的 SST 数据合并，从而向客户端提供包含最新写入的完整结果集：
+
+<p align="center">
+    <img src="/read-replica-data-read.png" alt="read-replica-data-read" width="600"/>
+</p>
+
+Follower Region 通过内部 gRPC 接口从 Leader Region 获取 memtable 数据。该过程会给 Leader Region 带来一定读负载，但由于 memtable 位于内存且大小受限，通常影响可控。
+
+## 下一步
+
+* [管理读副本](/enterprise/read-replicas/manage-read-replicas.md)
+* [从读副本查询](/enterprise/read-replicas/query-read-replicas.md)
+
+
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
new file mode 100644
index 000000000..5664995da
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
@@ -0,0 +1,95 @@
+---
+keywords: [企业版, 集群, 读副本, 查询, 读优先级]
+description: 在 GreptimeDB 企业版中从读副本查询的用法、读优先策略与示例。
+---
+
+# 从读副本查询
+
+GreptimeDB 允许从**读副本 (Follower Region)** 读取数据，从而降低写副本 (Leader Region) 的负载并提升查询伸缩性。您可以通过 **SQL** 与 **HTTP** 两种方式设置读优先策略。
+
+## 读优先策略
+
+`READ_PREFERENCE` 支持如下取值：
+
+- `leader`：始终从写副本读取。
+- `follower`：仅从读副本读取；若不存在读副本，则查询失败。
+- `follower_preferred`：优先从读副本读取；若不可用则回退到写副本。
+
+## SQL 协议
+
+在 SQL 会话中设置读优先：
+
+```sql
+SET READ_PREFERENCE = 'follower';
+```
+
+---
+
+## HTTP 协议
+
+在 HTTP 请求中通过请求头指定 `X-Greptime-Read-Preference`：
+
+```bash
+curl -X POST \
+  -H "Content-Type: application/x-www-form-urlencoded" \
+  -H "X-Greptime-Read-Preference: follower" \
+  -d "sql=select * from monitoring" \
+  http://localhost:4000/v1/sql
+```
+
+---
+
+## 示例：从读副本读取
+
+在从读副本读取之前，需要先为表添加读副本。参见[副本管理](/enterprise/read-replicas/replica-management.md)。
+
+向示例表插入数据：
+
+```sql
+INSERT INTO foo (ts, i, s)
+VALUES
+  (1, -1, 's1'),
+  (2, 0, 's2'),
+  (3, 1, 's3');
+```
+
+设置从读副本读取：
+
+```sql
+SET READ_PREFERENCE = 'follower';
+```
+
+查询数据：
+
+```sql
+SELECT * FROM foo ORDER BY ts;
+
++----------------------------+------+------+
+| ts                         | i    | s    |
++----------------------------+------+------+
+| 1970-01-01 00:00:00.001000 |   -1 | s1   |
+| 1970-01-01 00:00:00.002000 |    0 | s2   |
+| 1970-01-01 00:00:00.003000 |    1 | s3   |
++----------------------------+------+------+
+```
+
+---
+
+## 验证是否从读副本读取
+
+可以使用 `EXPLAIN ANALYZE` 进行验证：
+
+```sql
+EXPLAIN ANALYZE SELECT * FROM foo ORDER BY ts;
+```
+
+- 当输出中的 `other_ranges` 大于 0 时，表示查询涉及了读副本。
+- 若使用 `VERBOSE` 选项，将看到类似如下的详细信息：
+
+```plaintext
+extension_ranges: [LeaderMemtableRange{leader: Peer { id: 1, addr: "192.168.50.189:14101" }, num_rows: 2, time_range: (1::Millisecond, 2::Millisecond) ...
+```
+
+如果仅从写副本读取，上述 `extension_ranges` 段不会出现。
+
+
diff --git a/sidebars.ts b/sidebars.ts
index 02c936d9c..042b5a0e2 100644
--- a/sidebars.ts
+++ b/sidebars.ts
@@ -565,7 +565,15 @@ const sidebars: SidebarsConfig = {
           ],
         },
         'enterprise/console-ui',
-        'enterprise/read-replica',
+        {
+          type: 'category',
+          label: 'Read Replicas',
+          items: [
+            'enterprise/read-replicas/overview',
+            'enterprise/read-replicas/manage-read-replicas',
+            'enterprise/read-replicas/query-read-replicas',
+          ],
+        },
         'enterprise/trigger',
         {
           type: 'category',

From a6a094422319fc4f2cc4e9b437d3b51a1fbd4a7f Mon Sep 17 00:00:00 2001
From: WenyXu <wenymedia@gmail.com>
Date: Fri, 19 Sep 2025 17:11:57 +0800
Subject: [PATCH 2/6] fix: fix link

---
 docs/enterprise/overview.md                                     | 2 +-
 .../current/enterprise/overview.md                              | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/enterprise/overview.md b/docs/enterprise/overview.md
index 90c88dc14..5a6d0c601 100644
--- a/docs/enterprise/overview.md
+++ b/docs/enterprise/overview.md
@@ -35,7 +35,7 @@ which are described in detail in the documentation in this section:
 - [Elasticsearch query compatibility](./elasticsearch-compatible/overview.md): Use GreptimeDB backed Kibana for your logs.
 - [Greptime Enterprise Management Console](./console-ui.md): An enhanced version of our dashboard UI,
   carries more cluster management and monitoring features.
-- [Read Replica](./read-replica.md): Read-only datanode instances for heavy query workloads such as
+- [Read Replica](./read-replicas/overview.md): Read-only datanode instances for heavy query workloads such as
   analytical queries.
 - [Triggers](./trigger.md): Periodically evaluate your rules and trigger external
   webhook. Compatible with Prometheus AlterManager.
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/overview.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/overview.md
index bd8d4b454..a88cc0c77 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/overview.md
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/overview.md
@@ -31,7 +31,7 @@ GreptimeDB Enterprise 包括以下高级功能，
 - [自动分区平衡](./autopilot/region-balancer.md)：通过分区监控和迁移在 datanode 之间自动平衡负载。
 - [Elasticsearch 查询兼容性](./elasticsearch-compatible/overview.md)：在 Kibana 中以 GreptimeDB 作为后端。
 - [Greptime 企业版管理控制台](./console-ui.md)：加强版本的管理界面，提供更多的集群管理和监控功能。
-- [读副本](./read-replica.md)：专门运行复杂的查询操作的 datanode，避免影响实时写入。
+- [读副本](./read-replicas/overview.md)：专门运行复杂的查询操作的 datanode，避免影响实时写入。
 - [Trigger](./trigger.md)：定时查询和检测预配置的规则，可触发外部 webhook，兼容 Prometheus AlertManager。
 - Flow 的可靠性功能。
 

From 8f7cd93fb13f14ea509206ef7526b82568bdf227 Mon Sep 17 00:00:00 2001
From: WenyXu <wenymedia@gmail.com>
Date: Fri, 19 Sep 2025 17:22:03 +0800
Subject: [PATCH 3/6] fix: fix link

---
 docs/enterprise/read-replicas/query-read-replicas.md          | 4 ++--
 .../current/enterprise/read-replicas/query-read-replicas.md   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/enterprise/read-replicas/query-read-replicas.md b/docs/enterprise/read-replicas/query-read-replicas.md
index 46fa9865e..012083b7c 100644
--- a/docs/enterprise/read-replicas/query-read-replicas.md
+++ b/docs/enterprise/read-replicas/query-read-replicas.md
@@ -46,9 +46,9 @@ curl -X POST \
 
 ---
 
-## Example: Reading from Follower Replicas
+## Example: Reading from Read Replicas
 
-Before reading from Follower Replicas, you need to add Read Replicas to the table. See [Replica Management](/enterprise/read-replicas/replica-management.md) for more details.
+Before reading from Read Replicas, you need to add Read Replicas to the table. See [Replica Management](/enterprise/read-replicas/manage-read-replicas.md) for more details.
 
 Insert some data into a table:
 
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
index 5664995da..07a2b26a9 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
@@ -41,7 +41,7 @@ curl -X POST \
 
 ## 示例：从读副本读取
 
-在从读副本读取之前，需要先为表添加读副本。参见[副本管理](/enterprise/read-replicas/replica-management.md)。
+在从读副本读取之前，需要先为表添加读副本。参见[副本管理](/enterprise/read-replicas/manage-read-replicas.md)。
 
 向示例表插入数据：
 

From e80b799ef8933e98b67576e792f8454310316fa9 Mon Sep 17 00:00:00 2001
From: WenyXu <wenymedia@gmail.com>
Date: Fri, 19 Sep 2025 17:52:51 +0800
Subject: [PATCH 4/6] chore: apply suggestions

---
 .../deploy-on-kubernetes/configure-datanode-groups.md           | 2 +-
 docs/enterprise/read-replicas/manage-read-replicas.md           | 2 +-
 .../current/enterprise/read-replicas/query-read-replicas.md     | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md b/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
index 394b82ff3..e75ac840e 100644
--- a/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
+++ b/docs/enterprise/deployments-administration/deploy-on-kubernetes/configure-datanode-groups.md
@@ -97,4 +97,4 @@ weny-cluster-meta-58977b7897-8k2sf           1/1     Running   0          90s
 
 - For best performance, it is recommended to [Configure frontend groups](/user-guide/deployments-administration/deploy-on-kubernetes/configure-frontend-groups.md), which ensures complete separation of read and write traffic, achieving maximum isolation. 
 
-- Add Read Replica for your table, please refer to [Read Replica](/enterprise/read-replicas/overview.md).
\ No newline at end of file
+- Add Read Replica for your table, please refer to [Read Replica](/enterprise/read-replicas/overview.md).
diff --git a/docs/enterprise/read-replicas/manage-read-replicas.md b/docs/enterprise/read-replicas/manage-read-replicas.md
index ba57c3140..9b9e26ec8 100644
--- a/docs/enterprise/read-replicas/manage-read-replicas.md
+++ b/docs/enterprise/read-replicas/manage-read-replicas.md
@@ -178,4 +178,4 @@ ADMIN REMOVE_REGION_FOLLOWER(4398046511104, 2);
 
 ## Next steps
 
-* [Query Read Replicas](/enterprise/read-replicas/query-read-replicas.md)
\ No newline at end of file
+* [Query Read Replicas](/enterprise/read-replicas/query-read-replicas.md)
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
index 07a2b26a9..f7391eb52 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/query-read-replicas.md
@@ -5,7 +5,7 @@ description: 在 GreptimeDB 企业版中从读副本查询的用法、读优先
 
 # 从读副本查询
 
-GreptimeDB 允许从**读副本 (Follower Region)** 读取数据，从而降低写副本 (Leader Region) 的负载并提升查询伸缩性。您可以通过 **SQL** 与 **HTTP** 两种方式设置读优先策略。
+GreptimeDB 允许从**读副本 (Follower Region)** 读取数据，从而降低写副本 (Leader Region) 的负载并提升查询伸缩性。你可以通过 **SQL** 与 **HTTP** 两种方式设置读优先策略。
 
 ## 读优先策略
 

From e12823fdbc94e7d1fad955aacb283f14fb833be7 Mon Sep 17 00:00:00 2001
From: Weny Xu <wenymedia@gmail.com>
Date: Fri, 19 Sep 2025 19:24:20 +0800
Subject: [PATCH 5/6] Apply suggestion from @nicecui

Co-authored-by: Yiran <cuiyiran3@gmail.com>
---
 docs/enterprise/read-replicas/overview.md | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/docs/enterprise/read-replicas/overview.md b/docs/enterprise/read-replicas/overview.md
index bac1f4db8..13569addf 100644
--- a/docs/enterprise/read-replicas/overview.md
+++ b/docs/enterprise/read-replicas/overview.md
@@ -13,9 +13,6 @@ In the Read Replica mechanism, clients write data to the **Leader Region (write
     <img src="/read-replica-overview.png" alt="read-replica-overview" width="600"/>
 </p>
 
-::::tip NOTE
-The Read Replica feature is exclusive to the GreptimeDB Enterprise Cluster Edition.
-::::
 
 ## Principles
 

From f570ab5773db144fa0b6531d6b9a2879366f25db Mon Sep 17 00:00:00 2001
From: Weny Xu <wenymedia@gmail.com>
Date: Fri, 19 Sep 2025 19:24:32 +0800
Subject: [PATCH 6/6] Update
 i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md

Co-authored-by: Yiran <cuiyiran3@gmail.com>
---
 .../current/enterprise/read-replicas/overview.md               | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md
index 44f2ae9a4..d59e5a342 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/enterprise/read-replicas/overview.md
@@ -13,9 +13,6 @@ description: GreptimeDB 企业版读副本功能的概述与原理。
     <img src="/read-replica-overview.png" alt="read-replica-overview" width="600"/>
 </p>
 
-::::tip NOTE
-读副本功能仅在 GreptimeDB 企业集群版中提供。
-::::
 
 ## 原理