docs: fix inaccurate table names, links, and claims in the user guide

docs/user-guide/deployments-administration/deploy-on-kubernetes/overview.md

@@ -35,7 +35,7 @@ Once you are familiar with [the architecture and components of GreptimeDB](/user
 - [Deploy GreptimeDB Infrastructure test](deploy-greptimedb-infra-test.md): Prerequisite infrastructure testing for installing GreptimeDB.
 - [Deploy MinIO cluster](deploy-minio.md): Learn how to deploy, configure, and monitor a MinIO cluster.
 - [Deploy Kafka cluster](deploy-kafka.md): Learn how to deploy, configure, and monitor a Kafka cluster.
-- [Deploy GreptimeDB Cluster with Remote WAL](configure-remote-wal.md): Configure Kafka as a remote write-ahead log (WAL) for your GreptimeDB cluster to persistently record every data modification and ensure no loss of memory-cached data.
+- [Deploy GreptimeDB Cluster with Remote WAL](configure-remote-wal.md): Configure Kafka as a remote write-ahead log (WAL) for your GreptimeDB cluster, so writes that a Datanode has not yet flushed to storage can be replayed from Kafka after a failure.
 - [Use MySQL/PostgreSQL as Metadata Store](/user-guide/deployments-administration/deploy-on-kubernetes/common-helm-chart-configurations.md#configuring-metasrv-backend-storage): Store cluster metadata in a MySQL or PostgreSQL database.
 - [Deploy Multi-Frontend GreptimeDB Cluster](configure-frontend-groups.md): Set up a GreptimeDB cluster on Kubernetes with a frontend group consisting of multiple frontend instances for improved load distribution and availability.
 

docs/user-guide/deployments-administration/disaster-recovery/back-up-&-restore-data.md

@@ -86,8 +86,10 @@ greptime cli data export \
 
 ## Import Operations
 
-### Full Databases Backup
-Import all databases backup.
+<AnchorAlias id="full-databases-backup-1" />
+
+### Full Databases Import
+Import every database from a backup directory produced by `greptime cli data export`.
 ```bash
 # Import all databases
 greptime cli data import \
@@ -104,7 +106,9 @@ greptime cli data import \
     --auth-basic <username>:<password>
 ```
 
-### Schema-Only Operations
+<AnchorAlias id="schema-only-operations-1" />
+
+### Schema-Only Import
 Import only schemas without data. This operation imports `CREATE TABLE` statements from SQL files, allowing you to restore table structures without the actual data.
 ```bash
 # Import only schemas
@@ -114,9 +118,11 @@ greptime cli data import \
     --target schema
 ```
 
-### Specific Database Backup
+<AnchorAlias id="specific-database-backup-1" />
+
+### Specific Database Import
 ```bash
-# The same applies to import tool
+# Import a specific database
 greptime cli data import \
     --addr localhost:4000 \
     --input-dir /tmp/backup/greptimedb \

docs/user-guide/deployments-administration/overview.md

@@ -26,7 +26,7 @@ This section outlines the key aspects of deploying and administering GreptimeDB
 ### Component Management
 
 - **Cluster Failover:** Set up [Remote WAL](./wal/remote-wal/configuration.md) for high availability.
-- **Manage Metadata:** Set up [Metadata Storage](./manage-data/overview.md) for GreptimeDB.
+- **Manage Metadata:** Set up [Metadata Storage](./manage-metadata/overview.md) for GreptimeDB.
 
 ### Monitoring
 

docs/user-guide/flow-computation/overview.md

@@ -34,10 +34,10 @@ This process is visually represented in the following image:
 ## Quick Start Example
 
 As an example, count user agents in nginx logs.
-The source table is `nginx_access_log`,
+The source table is `ngx_http_log`,
 and the sink table is `user_agent_statistics`.
 
-First, create the source table `nginx_access_log`.
+First, create the source table `ngx_http_log`.
 To optimize performance for counting the `user_agent` field,
 specify it as a `TAG` column type using the `PRIMARY KEY` keyword.
 

docs/user-guide/logs/use-custom-pipelines.md

@@ -92,7 +92,7 @@ contains `processors` and `transform` sections that work together to structure y
 - **Data Extraction**: The `dissect` processor uses pattern matching to parse the `message` field and extract structured data including `ip_address`, `timestamp`, `http_method`, `request_line`, `status_code`, `response_size`, and `user_agent`.
 - **Timestamp Processing**: The `date` processor parses the extracted `timestamp` field using the format `%d/%b/%Y:%H:%M:%S %z` and converts it to a proper timestamp data type.
 - **Field Selection**: The `select` processor excludes the original `message` field from the final output while retaining all other fields.
-- **Table Options**: The `vrl` processor sets the table options based on the extracted fields, such as adding a suffix to the table name and setting the TTL. The `greptime_ttl = "7d"` line configures the table data to have a time-to-live of 7 days.
+- **Table Options**: The `vrl` processor sets table options on the rows it emits. Here the `.greptime_ttl = "7d"` line gives the table a 7-day time-to-live.
 
 **Transform**: Defines how to convert and index the extracted fields:
 - **Field Transformation**: Each extracted field is converted to its appropriate data type with specific indexing configurations. Fields like `http_method` retain their default data types when no explicit configuration is provided.

i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/deploy-on-kubernetes/overview.md

@@ -35,7 +35,7 @@ GreptimeDB Operator 在 Kubernetes 上自动完成 GreptimeDB 实例的部署、
 - [部署 GreptimeDB 基础设施测试](deploy-greptimedb-infra-test.md)： 安装 GreptimeDB 的前置基础设施测试检查。
 - [部署 MinIO 集群](deploy-minio.md)：学习如何部署，配置和监控 MinIO 集群。
 - [部署 Kafka 集群](deploy-kafka.md)：学习如何部署，配置和监控 Kafka 集群。
-- [部署带有 Remote WAL 的 GreptimeDB 集群](configure-remote-wal.md)：将 Kafka 配置为 GreptimeDB 集群的远程预写日志 (WAL)，以持久记录每个数据修改并确保不丢失内存缓存的数据。
+- [部署带有 Remote WAL 的 GreptimeDB 集群](configure-remote-wal.md)：将 Kafka 配置为 GreptimeDB 集群的远程预写日志 (WAL)，Datanode 尚未落盘的写入可以在故障后从 Kafka 回放。
 - [使用 MySQL/PostgreSQL 作为元数据存储](/user-guide/deployments-administration/deploy-on-kubernetes/common-helm-chart-configurations.md#配置-metasrv-后端存储)：用 MySQL 或 PostgreSQL 数据库存储集群元数据。
 - [部署多 Frontend 的 GreptimeDB 集群](configure-frontend-groups.md)：GreptimeDB 集群的 Frontend 组由多个 Frontend 实例组成，以改善负载分配和可用性。
 

i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/disaster-recovery/back-up-&-restore-data.md

@@ -86,8 +86,10 @@ greptime cli data export \
 
 ## 导入操作
 
-### 完整数据库备份
-导入所有数据库备份。
+<AnchorAlias id="完整数据库备份-1" />
+
+### 完整数据库导入
+从 `greptime cli data export` 生成的备份目录导入所有数据库。
 ```bash
 # 导入所有数据库
 greptime cli data import \
@@ -114,7 +116,9 @@ greptime cli data import \
     --target schema
 ```
 
-### 指定数据库备份
+<AnchorAlias id="指定数据库备份-1" />
+
+### 指定数据库导入
 ```bash
 # 导入指定数据库
 greptime cli data import \

i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/overview.md

@@ -26,7 +26,7 @@ GreptimeDB 可以部署在你自己的基础设施上，也可以通过全托管
 ### 组件管理
 
 - **Cluster Failover：** 通过设置 [Remote WAL](./wal/remote-wal/configuration.md) 以实现高可用性。
-- **管理元数据：** 为 GreptimeDB 设置[元数据存储](./manage-data/overview.md)。
+- **管理元数据：** 为 GreptimeDB 设置[元数据存储](./manage-metadata/overview.md)。
 
 ### 监控
 

i18n/zh/docusaurus-plugin-content-docs/current/user-guide/flow-computation/overview.md

@@ -34,10 +34,10 @@ source 表和 sink 表都是 GreptimeDB 中的时间序列表。
 ## 快速入门示例
 
 下面以统计 nginx 日志中的 user_agent 为例。
-source 表是 `nginx_access_log`，
+source 表是 `ngx_http_log`，
 sink 表是 `user_agent_statistics`。
 
-首先，创建 source 表 `nginx_access_log`。
+首先，创建 source 表 `ngx_http_log`。
 为了优化计算 `user_agent` 字段的性能，
 使用 `PRIMARY KEY` 关键字将其指定为 `TAG` 列类型。
 
@@ -86,10 +86,10 @@ GROUP BY
 ```
 
 一旦创建了 Flow，
-Flow 引擎将持续处理 `nginx_access_log` 表中的数据，并使用计算结果更新 `user_agent_statistics` 表。
+Flow 引擎将持续处理 `ngx_http_log` 表中的数据，并使用计算结果更新 `user_agent_statistics` 表。
 
 要观察 Flow 的结果，
-将示例数据插入 `nginx_access_log` 表。
+将示例数据插入 `ngx_http_log` 表。
 
 ```sql
 INSERT INTO ngx_http_log

i18n/zh/docusaurus-plugin-content-docs/current/user-guide/logs/use-custom-pipelines.md

@@ -93,7 +93,7 @@ transform:
 - **数据提取**：`dissect` 处理器使用 pattern 匹配来解析 `message` 字段并提取结构化数据，包括 `ip_address`、`timestamp`、`http_method`、`request_line`、`status_code`、`response_size` 和 `user_agent`。
 - **时间戳处理**：`date` 处理器使用格式 `%d/%b/%Y:%H:%M:%S %z` 解析提取的 `timestamp` 字段并将其转换为适当的时间戳数据类型。
 - **字段选择**：`select` 处理器从最终输出中排除原始 `message` 字段，同时保留所有其他字段。
-- **表选项**：`vrl` 处理器根据提取的字段设置表选项，例如向表名添加后缀和设置 TTL。`greptime_ttl = "7d"` 配置表数据的保存时间为 7 天。
+- **表选项**：`vrl` 处理器为写出的数据行设置表选项。这里的 `.greptime_ttl = "7d"` 把表数据的保存时间设为 7 天。
 
 **Transform**：定义如何转换和索引提取的字段：
 - **字段转换**：每个提取的字段都转换为适当的数据类型并根据需要配置相应的索引。像 `http_method` 这样的字段在没有提供显式配置时保留其默认数据类型。

i18n/zh/docusaurus-plugin-content-docs/version-1.1/user-guide/deployments-administration/deploy-on-kubernetes/overview.md

@@ -35,7 +35,7 @@ GreptimeDB Operator 在 Kubernetes 上自动完成 GreptimeDB 实例的部署、
 - [部署 GreptimeDB 基础设施测试](deploy-greptimedb-infra-test.md)： 安装 GreptimeDB 的前置基础设施测试检查。
 - [部署 MinIO 集群](deploy-minio.md)：学习如何部署，配置和监控 MinIO 集群。
 - [部署 Kafka 集群](deploy-kafka.md)：学习如何部署，配置和监控 Kafka 集群。
-- [部署带有 Remote WAL 的 GreptimeDB 集群](configure-remote-wal.md)：将 Kafka 配置为 GreptimeDB 集群的远程预写日志 (WAL)，以持久记录每个数据修改并确保不丢失内存缓存的数据。
+- [部署带有 Remote WAL 的 GreptimeDB 集群](configure-remote-wal.md)：将 Kafka 配置为 GreptimeDB 集群的远程预写日志 (WAL)，Datanode 尚未落盘的写入可以在故障后从 Kafka 回放。
 - [使用 MySQL/PostgreSQL 作为元数据存储](/user-guide/deployments-administration/deploy-on-kubernetes/common-helm-chart-configurations.md#配置-metasrv-后端存储)：用 MySQL 或 PostgreSQL 数据库存储集群元数据。
 - [部署多 Frontend 的 GreptimeDB 集群](configure-frontend-groups.md)：GreptimeDB 集群的 Frontend 组由多个 Frontend 实例组成，以改善负载分配和可用性。
 

i18n/zh/docusaurus-plugin-content-docs/version-1.1/user-guide/deployments-administration/disaster-recovery/back-up-&-restore-data.md

@@ -84,8 +84,10 @@ greptime cli data export \
 
 ## 导入操作
 
-### 完整数据库备份
-导入所有数据库备份。
+<AnchorAlias id="完整数据库备份-1" />
+
+### 完整数据库导入
+从 `greptime cli data export` 生成的备份目录导入所有数据库。
 ```bash
 # 导入所有数据库
 greptime cli data import \
@@ -112,7 +114,9 @@ greptime cli data import \
     --target schema
 ```
 
-### 指定数据库备份
+<AnchorAlias id="指定数据库备份-1" />
+
+### 指定数据库导入
 ```bash
 # 导入指定数据库
 greptime cli data import \

i18n/zh/docusaurus-plugin-content-docs/version-1.1/user-guide/deployments-administration/overview.md

@@ -26,7 +26,7 @@ GreptimeDB 可以部署在你自己的基础设施上，也可以通过全托管
 ### 组件管理
 
 - **Cluster Failover：** 通过设置 [Remote WAL](./wal/remote-wal/configuration.md) 以实现高可用性。
-- **管理元数据：** 为 GreptimeDB 设置[元数据存储](./manage-data/overview.md)。
+- **管理元数据：** 为 GreptimeDB 设置[元数据存储](./manage-metadata/overview.md)。
 
 ### 监控
 

i18n/zh/docusaurus-plugin-content-docs/version-1.1/user-guide/flow-computation/overview.md

@@ -34,10 +34,10 @@ source 表和 sink 表都是 GreptimeDB 中的时间序列表。
 ## 快速入门示例
 
 下面以统计 nginx 日志中的 user_agent 为例。
-source 表是 `nginx_access_log`，
+source 表是 `ngx_http_log`，
 sink 表是 `user_agent_statistics`。
 
-首先，创建 source 表 `nginx_access_log`。
+首先，创建 source 表 `ngx_http_log`。
 为了优化计算 `user_agent` 字段的性能，
 使用 `PRIMARY KEY` 关键字将其指定为 `TAG` 列类型。
 
@@ -86,10 +86,10 @@ GROUP BY
 ```
 
 一旦创建了 Flow，
-Flow 引擎将持续处理 `nginx_access_log` 表中的数据，并使用计算结果更新 `user_agent_statistics` 表。
+Flow 引擎将持续处理 `ngx_http_log` 表中的数据，并使用计算结果更新 `user_agent_statistics` 表。
 
 要观察 Flow 的结果，
-将示例数据插入 `nginx_access_log` 表。
+将示例数据插入 `ngx_http_log` 表。
 
 ```sql
 INSERT INTO ngx_http_log

i18n/zh/docusaurus-plugin-content-docs/version-1.1/user-guide/logs/use-custom-pipelines.md

@@ -93,7 +93,7 @@ transform:
 - **数据提取**：`dissect` 处理器使用 pattern 匹配来解析 `message` 字段并提取结构化数据，包括 `ip_address`、`timestamp`、`http_method`、`request_line`、`status_code`、`response_size` 和 `user_agent`。
 - **时间戳处理**：`date` 处理器使用格式 `%d/%b/%Y:%H:%M:%S %z` 解析提取的 `timestamp` 字段并将其转换为适当的时间戳数据类型。
 - **字段选择**：`select` 处理器从最终输出中排除原始 `message` 字段，同时保留所有其他字段。
-- **表选项**：`vrl` 处理器根据提取的字段设置表选项，例如向表名添加后缀和设置 TTL。`greptime_ttl = "7d"` 配置表数据的保存时间为 7 天。
+- **表选项**：`vrl` 处理器为写出的数据行设置表选项。这里的 `.greptime_ttl = "7d"` 把表数据的保存时间设为 7 天。
 
 **Transform**：定义如何转换和索引提取的字段：
 - **字段转换**：每个提取的字段都转换为适当的数据类型并根据需要配置相应的索引。像 `http_method` 这样的字段在没有提供显式配置时保留其默认数据类型。

i18n/zh/docusaurus-plugin-content-docs/version-1.2/user-guide/deployments-administration/deploy-on-kubernetes/overview.md

@@ -35,7 +35,7 @@ GreptimeDB Operator 在 Kubernetes 上自动完成 GreptimeDB 实例的部署、
 - [部署 GreptimeDB 基础设施测试](deploy-greptimedb-infra-test.md)： 安装 GreptimeDB 的前置基础设施测试检查。
 - [部署 MinIO 集群](deploy-minio.md)：学习如何部署，配置和监控 MinIO 集群。
 - [部署 Kafka 集群](deploy-kafka.md)：学习如何部署，配置和监控 Kafka 集群。
-- [部署带有 Remote WAL 的 GreptimeDB 集群](configure-remote-wal.md)：将 Kafka 配置为 GreptimeDB 集群的远程预写日志 (WAL)，以持久记录每个数据修改并确保不丢失内存缓存的数据。
+- [部署带有 Remote WAL 的 GreptimeDB 集群](configure-remote-wal.md)：将 Kafka 配置为 GreptimeDB 集群的远程预写日志 (WAL)，Datanode 尚未落盘的写入可以在故障后从 Kafka 回放。
 - [使用 MySQL/PostgreSQL 作为元数据存储](/user-guide/deployments-administration/deploy-on-kubernetes/common-helm-chart-configurations.md#配置-metasrv-后端存储)：用 MySQL 或 PostgreSQL 数据库存储集群元数据。
 - [部署多 Frontend 的 GreptimeDB 集群](configure-frontend-groups.md)：GreptimeDB 集群的 Frontend 组由多个 Frontend 实例组成，以改善负载分配和可用性。
 

i18n/zh/docusaurus-plugin-content-docs/version-1.2/user-guide/deployments-administration/disaster-recovery/back-up-&-restore-data.md

@@ -86,8 +86,10 @@ greptime cli data export \
 
 ## 导入操作
 
-### 完整数据库备份
-导入所有数据库备份。
+<AnchorAlias id="完整数据库备份-1" />
+
+### 完整数据库导入
+从 `greptime cli data export` 生成的备份目录导入所有数据库。
 ```bash
 # 导入所有数据库
 greptime cli data import \
@@ -114,7 +116,9 @@ greptime cli data import \
     --target schema
 ```
 
-### 指定数据库备份
+<AnchorAlias id="指定数据库备份-1" />
+
+### 指定数据库导入
 ```bash
 # 导入指定数据库
 greptime cli data import \

i18n/zh/docusaurus-plugin-content-docs/version-1.2/user-guide/deployments-administration/overview.md

@@ -26,7 +26,7 @@ GreptimeDB 可以部署在你自己的基础设施上，也可以通过全托管
 ### 组件管理
 
 - **Cluster Failover：** 通过设置 [Remote WAL](./wal/remote-wal/configuration.md) 以实现高可用性。
-- **管理元数据：** 为 GreptimeDB 设置[元数据存储](./manage-data/overview.md)。
+- **管理元数据：** 为 GreptimeDB 设置[元数据存储](./manage-metadata/overview.md)。
 
 ### 监控
 

i18n/zh/docusaurus-plugin-content-docs/version-1.2/user-guide/flow-computation/overview.md

@@ -34,10 +34,10 @@ source 表和 sink 表都是 GreptimeDB 中的时间序列表。
 ## 快速入门示例
 
 下面以统计 nginx 日志中的 user_agent 为例。
-source 表是 `nginx_access_log`，
+source 表是 `ngx_http_log`，
 sink 表是 `user_agent_statistics`。
 
-首先，创建 source 表 `nginx_access_log`。
+首先，创建 source 表 `ngx_http_log`。
 为了优化计算 `user_agent` 字段的性能，
 使用 `PRIMARY KEY` 关键字将其指定为 `TAG` 列类型。
 
@@ -86,10 +86,10 @@ GROUP BY
 ```
 
 一旦创建了 Flow，
-Flow 引擎将持续处理 `nginx_access_log` 表中的数据，并使用计算结果更新 `user_agent_statistics` 表。
+Flow 引擎将持续处理 `ngx_http_log` 表中的数据，并使用计算结果更新 `user_agent_statistics` 表。
 
 要观察 Flow 的结果，
-将示例数据插入 `nginx_access_log` 表。
+将示例数据插入 `ngx_http_log` 表。
 
 ```sql
 INSERT INTO ngx_http_log

i18n/zh/docusaurus-plugin-content-docs/version-1.2/user-guide/logs/use-custom-pipelines.md

@@ -93,7 +93,7 @@ transform:
 - **数据提取**：`dissect` 处理器使用 pattern 匹配来解析 `message` 字段并提取结构化数据，包括 `ip_address`、`timestamp`、`http_method`、`request_line`、`status_code`、`response_size` 和 `user_agent`。
 - **时间戳处理**：`date` 处理器使用格式 `%d/%b/%Y:%H:%M:%S %z` 解析提取的 `timestamp` 字段并将其转换为适当的时间戳数据类型。
 - **字段选择**：`select` 处理器从最终输出中排除原始 `message` 字段，同时保留所有其他字段。
-- **表选项**：`vrl` 处理器根据提取的字段设置表选项，例如向表名添加后缀和设置 TTL。`greptime_ttl = "7d"` 配置表数据的保存时间为 7 天。
+- **表选项**：`vrl` 处理器为写出的数据行设置表选项。这里的 `.greptime_ttl = "7d"` 把表数据的保存时间设为 7 天。
 
 **Transform**：定义如何转换和索引提取的字段：
 - **字段转换**：每个提取的字段都转换为适当的数据类型并根据需要配置相应的索引。像 `http_method` 这样的字段在没有提供显式配置时保留其默认数据类型。

versioned_docs/version-1.1/user-guide/deployments-administration/deploy-on-kubernetes/overview.md

@@ -35,7 +35,7 @@ Once you are familiar with [the architecture and components of GreptimeDB](/user
 - [Deploy GreptimeDB Infrastructure test](deploy-greptimedb-infra-test.md): Prerequisite infrastructure testing for installing GreptimeDB.
 - [Deploy MinIO cluster](deploy-minio.md): Learn how to deploy, configure, and monitor a MinIO cluster.
 - [Deploy Kafka cluster](deploy-kafka.md): Learn how to deploy, configure, and monitor a Kafka cluster.
-- [Deploy GreptimeDB Cluster with Remote WAL](configure-remote-wal.md): Configure Kafka as a remote write-ahead log (WAL) for your GreptimeDB cluster to persistently record every data modification and ensure no loss of memory-cached data.
+- [Deploy GreptimeDB Cluster with Remote WAL](configure-remote-wal.md): Configure Kafka as a remote write-ahead log (WAL) for your GreptimeDB cluster, so writes that a Datanode has not yet flushed to storage can be replayed from Kafka after a failure.
 - [Use MySQL/PostgreSQL as Metadata Store](/user-guide/deployments-administration/deploy-on-kubernetes/common-helm-chart-configurations.md#configuring-metasrv-backend-storage): Store cluster metadata in a MySQL or PostgreSQL database.
 - [Deploy Multi-Frontend GreptimeDB Cluster](configure-frontend-groups.md): Set up a GreptimeDB cluster on Kubernetes with a frontend group consisting of multiple frontend instances for improved load distribution and availability.